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INTRODUCTION 


This  VV& A  task  (RT  21)  had  two  parallel  components  which  converged  to 
provide  recommendations  on  methods,  languages  and  tools  for  most  effective 
Modeling  and  Simulation  (M&S)  of  complex  systems  as  a  means  for  Verification, 
Validation  and  Accreditation.  One  component,  performed  by  University  of 
Alabama  Huntsville,  is  focused  on  an  AADL  approach,  and  exploits  synergies 
with  other  related  efforts  being  conducted  by  the  SAVI  consortium.  The  other 
component,  performed  by  Georgia  Institute  of  Technology,  is  focused  on  a 
SYSML  based  approach.  Both  components  begin  with  building  an 
understanding  of  the  current  M&S  environment  with  a  focus  on  gaps  in  M&S 
approaches,  methods  and  tools  being  capable  of  supporting  effective  VV&A. 
A  common  assessment  approach  will  inform  both  teams  about  the  current 
environment  and  gaps. 

This  Final  Technical  Report  is  broken  down  into  two  components: 

University  of  Alabama  Huntsville  -  pages  3-33 
Georgia  Institute  of  Technology  -  pages  34-159 
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Abstract 


As  systems  become  more  software  intensive  and  complex,  managing  their  development 
and  implementation  also  becomes  more  complex.  Models  in  development  today  are 
isolated,  domain-specific  artifacts  that  are  created  throughout  the  design  lifecycle.  A 
mechanism  is  needed  to  integrate  the  design  models  with  simulation  environments  as 
the  models  are  being  developed  and  refined  in  order  to  rapidly  see  the  impacts  as  the 
design  matures.  The  ability  to  perform  verification,  validation,  and  accreditation 
(W&A)  early  in  the  modeling  process  and  throughout  the  lifecycle  could  greatly 
improve  the  model  and  its  contribution.  But  in  order  to  perform  W&A  on  complex 
systems,  a  precise  language  would  be  required  to  model  these  systems  in  an  integrated 
fashion  to  remove  ambiguity  and  the  segmented  developmental  lifecycle. 

Objectives  of  this  research  included  exploring  the  unique  capabilities  of  Architectural 
Analysis  and  Design  Language  (AADL)  for  developing  high  confidence  (verified  and 
validated)  models  as  part  of  a  system  development  lifecycle  and  to  determine  the 
maturity  of  the  AADL  tools  for  W&A  model  refinement.  To  show  how  AADL  could  be 
used  to  embed  the  Verification  and  Validation  of  architectural  models  into  the 
development  process,  an  architectural  model  of  the  Army’s  Systems  Integration  and 
Test  Laboratory  (STIL)  was  developed  and  used  as  a  test  bed. 

The  results  of  the  research  showed  that  a  portion  of  a  real  world  DoD  representative 
system  could  be  modeled  using  AADL  in  a  very  short  time  with  little  previous  experience 
in  AADL.  AADL’s  well-defined  semantics  supported  Architecture/System  Design 
verification  by  allowing  a  precise  specification  of  the  architecture  so  that  the  analysis 
performed  is  trustworthy  and  repeatable. 
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1  Summary 


As  systems  become  more  software  intensive  and  complex,  managing  their  development 
and  implementation  also  becomes  more  complex.  Modeling  portions  or  all  of  a  system 
is  becoming  more  essential  because  of  their  contributions  to  design  decisions  early  in 
the  lifecycle  that  can  impact  cost,  schedule,  and  performance.  Models  in  development 
today  are  isolated,  domain-specific  artifacts  that  are  created  throughout  the  design 
lifecycle.  A  mechanism  is  needed  to  integrate  the  design  models  with  simulation 
environments  as  the  models  are  being  developed  and  refined  in  order  to  rapidly  see  the 
impacts  as  the  design  matures.  The  ability  to  perform  verification,  validation,  and 
accreditation  (W&A)  early  in  the  modeling  process  and  throughout  the  lifecycle  could 
improve  the  model  and  its  contribution  greatly.  But  in  order  to  perform  W&A  on 
complex  systems,  a  precise  language  would  be  required  to  model  these  systems  in  an 
integrated  fashion  to  remove  ambiguity  and  the  segmented  developmental  lifecycle. 
Objectives  of  this  research  included  exploring  the  unique  capabilities  of  Architectural 
Analysis  and  Design  Language  (AADL)  for  developing  high  confidence  (verified  and 
validated)  models  as  part  of  a  system  development  lifecycle  and  to  determine  the 
maturity  of  the  AADL  tools  for  W&A  model  refinement.  To  show  how  AADL  could  be 
used  to  embed  the  Verification  and  Validation  of  architectural  models  into  the 
development  process,  an  architectural  model  of  the  Army’s  Systems  Integration  and 
Test  Laboratory  (STIL)  was  developed  and  used  as  a  test  bed. 

The  results  of  the  research  showed  that  a  portion  of  a  real  world  DoD  representative 
system  could  be  modeled  using  AADL  in  a  very  short  time  with  little  previous  experience 
in  AADL.  AADL’s  well-defined  semantics  supported  Architecture/System  Design 
verification  by  allowing  a  precise  specification  of  the  architecture  so  that  the  analysis 
performed  is  trustworthy  and  repeatable.  The  ability  to  use  custom  property  sets  within 
AADL  allowed  the  embedding  of  traceability  information  into  the  model.  The 
traceability  data  provided  a  mechanism  verify  of  values  contained  in  the  model  to  assist 
in  the  reusability  of  the  model  and  overall  verification  of  the  model. 

Possible  benefits  of  using  AADL  include  the  ability  to  perform  incremental  W&A  on 
system  architectures,  perform  trade  studies  on  crucial  components  of  the  system  and  to 
discern  deep  architectural  issues.  AADL  enables  the  detection  of  design  or  requirement 
problems  related  to  the  integration  of  the  system  and  system  level  qualities  while 
considering  the  impact  on  system  reliability  and  safety. 
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2  Introduction 


This  report  presents  the  research  and  findings  for  the  use  of  Architecture  Analysis  and 
Design  Language  (AADL)  and  tools  designed  with  AADL  for  the  verification,  validation 
and  accreditation  of  system  architectural  models.  The  University  of  Alabama  in 
Huntsville’s  (UAHuntsville)  Rotorcraft  Systems  Engineering  and  Simulations  Center 
(RSESC)  explored  the  unique  capabilities  AADL  offers  for  developing  high  confidence 
(verified  and  validated)  models  as  part  of  a  system  development  lifecycle.  Specifically, 
we  investigated  automated  verification  through  model  consistency,  semantic  checking 
and  traceability  between  the  requirements.  A  conceptual  model  and  a  runtime  model 
were  created  to  perform  constraint  checking  and  model  refinement  in  an  attempt  to 
show  how  AADL  can  improve  the  ability  to  verify  and  validate  a  system  or  simulation 
and  to  provide  evidence  that  the  accreditation  process  can  be  shortened.  In  order  to 
explore  the  potential  of  AADL,  a  Department  of  Defense  (DoD)  system  presently  under 
development  was  selected  as  pilot  project  or  test  candidate.  This  DoD  system,  the 
System  Test  and  Integration  Lab  (STIL),  was  modeled  to  understand  and  demonstrate 
AADL’s  capability  to  assist  in  incremental  Verification,  Validation  and  Accreditation 
(W&A).  Due  to  the  limited  scope  of  funding  and  time  duration,  the  research  was 
focused  on  the  Time,  Space,  Position  Information  (TSPI)  for  the  STIL.  Under  this  task 
we  also  leveraged  and  expanded  existing  System  Architecture  Virtual  Integration  (SAVI) 
and  AADL  research  in  the  area  of  incrementally  verifying  and  validating  using  the  AADL 
language. 

Funding  for  this  research  task  was  also  provided  by  the  Project  Manager  of 
Instrumentation,  Targets  and  Threat  Simulators  under  the  Program  Executive  Office  for 
Simulation,  Training  and  Instrumentation,  (PEO-STRI/PM-ITTS)  and  informational 
support  was  provided  by  the  Aviation  Flight  Test  Directorate.  This  research  work  was 
done  in  partnership  with  the  Aerospace  Vehicle  Systems  Institute  (AVSI)  Consortium 
and  the  AADL’s  users  group  who  participated  in  many  of  the  briefings  to  the  sponsor. 


2.1  Background 

The  RSESC  at  the  UAHuntsville  has  been  working  with  many  of  the  Army’s  Redstone 
Arsenal  offices  and  several  other  Army  and  Navy  offices  for  many  years  assisting  with 
systems  engineering  and  system  design  problems.  Over  the  last  six  months,  RSESC  has 
been  working  with  the  Army’s  Aviation  Engineering  Directorate  (AED)  and  Software 
Engineering  Directorate  (SED)  under  the  U.S.  Army’s  Aviation  and  Missile  Research, 
Development  Engineering  Center  (AMRDEC)  on  how  to  manage  complex  systems 
including  verifying  and  validating  these  systems.  It  is  believed  that  a  transition  is 
required  from  document-centric  requirements  to  integrated  mathematical  models  to 
verify  and  validate  those  requirements. 
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Presently,  there  is  not  a  way  to  predict  the  performance  of  complex  systems  all  the  way 
through  integration.  Software  and  system  design  languages  are  loosely  defined  and 
therefore  do  not  provide  the  precise  definition  needed  for  high  fidelity  simulation  and 
quantitative  modeling  and  formal  methods.  When  considering  analysis  tools  there  is  a 
limitation  in  their  capability  to  work  together;  therefore  problems  are  typically  found 
after  the  systems  are  built.  It  is  believed  that  an  architectural  context  is  needed  to 
resolve  this  issue.  A  high-level  architecture  specification  allows  end-to-end  analysis  or 
simulation  of  the  complete  system  to  help  ensure  system  success  before  system 
integration  and  test. 

Models  must  be  developed  with  a  common  understanding  of  the  semantics  of  the 
modeling  elements  in  order  to  allow  the  integration  of  architectural  models.  Not  having 
precise  semantics  and  a  common  understanding  of  those  semantics  results  in  difficulty 
during  the  verification  process  due  to  the  lack  of  precise  analysis  capability.  The 
utilization  of  a  custom  language  leads  to  a  need  to  define  and  document  it  well.  Upkeep 
and  revalidation  of  assumptions  become  an  issue  each  time  models  that  have  their  own 
semantics  are  integrated.1 

As  part  of  this  effort  to  resolve  the  shortfalls  of  the  current  analysis  tools  used  for  W&A, 
research  has  been  done  to  determine  the  best  tools  for  verification,  validation  and 
accreditation  of  architectural  models.  Presently  AED  and  SED  are  investigating  the  use 
of  AADL  as  a  formal  architecture  language  in  coordination  with  the  SAVI  consortium. 

In  partnership  with  AED  and  SED,  RSESC  has  attended  courses  and  seminars  on  the 
topic.  RSESC  has  also  been  actively  involved  in  developing  expertise  in  the  AADL 
specification,  model  based  engineering  and  toolsets  that  would  be  used  in  coordination 
with  the  AADL  model. 

For  this  research  task  RSESC  leveraged  other  research  work  currently  on  contract  with 
the  U.S.  Army.  These  efforts  include  working  with  PEO-STRI  on  establishing  the 
baseline  requirements  and  architectural  format  for  Block  II  of  the  Redstone  Test 
Center’s  System  Test  and  Integration  Lab. 


2.1 .1  System  Architecture  Virtual  Integration  Background 

SAVI  is  an  international  industry  consortium  developing  a  new  capability  for  early 
verification  and  validation  of  architecture  supporting  acquisition  and  development. 
SAVI  participants  are  Boeing,  Airbus,  Lockheed  Martin,  British  Aerospace  Engineering 
Systems,  Rockwell,  Goodrich,  Federal  Aviation  Administration,  Department  of  Defense 
(DoD),  and  Carnegie  Mellon  (CMU)  Software  Engineering  Institute  (SEI). 

The  SAVI  is  a  five  year  endeavor  that  is  presently  in  its  second  year  of  research.  It  is  a 
research  effort  to  define  the  standards  and  technologies  needed  to  effect  virtual 
integration.  The  project  is  intended  to  be  a  global  collaboration  to  integrate  three 
emerging  technologies:  Model-based,  Proof-Based,  and  Component-Based  engineering. 
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One  of  SAVT’s  goals  is  to  determine  methods  for  structured/transformable  data 
interfaces  to  change  the  acquisition  paradigm  to  facilitate  systems  integration.  SAVI  is 
not  a  software  tool  or  a  design  tool  or  a  continuation  of  current  system  development 
practices. 

SAVI  is  investigating  extending  the  semantic  architecture  model  using  the  extensibility 
mechanism  of  AADL  to  support  the  capture  and  validation  of  requirements.  “The  end- 
to-end  validation  of  systems  involves  validation  of  requirements  against  system  models 
and  system  implementation.  AADL  properties  support  basic  traceability  between  a 
requirements  document  and  models,  as  well  as  traceability  from  models  to 
implementation  in  the  form  of  detailed  design  models  and  source  code.”2  Additional 
detail  on  the  System  Architecture  Virtual  Integration  and  the  work  that  has  been  done 
can  be  provided  upon  request. 

Participants  in  the  SAVI  project  were  and  continue  to  be  open  to  collaboration  with 
RSESC  in  the  research  being  performed  on  AADL  toolsets.  RSESC’s  experience  in 
rotorcraft,  space  and  ground  support  systems  is  of  benefit  to  the  missions  and  goals  for 
W&A.  Evaluating  these  tools  and  developing  expertise  in  AADL  specification  provides 
UAHuntsville  with  state  of  the  art  capability  to  impact  system  integration  and 
verification  and  validation. 


2.1 .2  System  Test  Integration  Lab  Overview 

Digital  transformation  has  resulted  in  a  new  generation  of  complex  aircraft,  constituting 
a  new  type  of  airborne  “System  of  Systems.”  These  new  aircraft  require  a  robust 
hardware  and  software  environment  for  intelligent  test  and  control  that  can  efficiently 
test  these  aircraft  in  a  real-time  integrated  system  environment.  This  requires  an 
analytical/intelligent  philosophy  for  the  evaluation  of  sophisticated  complex  systems. 
The  STIL  is  intended  to  be  an  installed  system  test  facility  that  will  provide  a  synthetic 
environment  capable  of  immersing  an  instrumented  aircraft  and  its  system  in  a 
controlled,  repeatable  and  distributed  virtual  environment  to  enhance  test  capability; 
augment  open-air  testing;  mitigate  program  risk,  cost  and  schedule;  and  provide  a 
collaborative  environment  for  system  of  systems  testing.3  This  vision  of  the  STIL  is 
presented  in  Figure  l,  and  actual  photos  of  the  facility  from  a  January  2011  tour  follow. 

The  STIL  was  selected  for  the  research  because  it  provided  a  real-world  DoD  system 
integration  challenge.  The  STIL  is  a  software-intensive  distributed  system  that  must 
produce  precise  and  deterministic  event  ordering  to  meet  requirements.  It  is  a 
multifaceted  system  involving  simulation  and  stimulation  allowing  for  the  ability  to 
expand  the  AADL  model  into  more  areas/disciplines.  Lastly,  the  AADL  model  of  the 
STIL  allows  the  analysis  of  various  characteristics  of  the  STIL  architecture. 
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Backbone 


Slide  Provided  by  PEO-STRI  /  PMdTTS 

Figure  l:  STIL  Concept  Models 


Figure  2:  CH-47  Aircraft  a  Future  Aircraft  to  be  Tested  in  the  STIL 
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Figure  3:  Picture  inside  of  the  CH-47  Aircraft  within  the  STIL  Hanger 


Figure  4:  Picture  of  the  STIL  Stimulation  Hardware 
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2.2  Current  Practice 

Presently,  complex  systems  are  becoming  more  reliant  on  software  and  embedded  real 
time  controllers.  Modeling  portions  or  all  of  a  system  is  highly  useful  because  it  can 
contribute  early  in  the  lifecycle  to  design  decisions  that  impact  cost,  schedule,  and 
performance.  Models  in  development  today  are  isolated,  domain-specific  artifacts  that 
are  created  throughout  the  design  lifecycle.  Models  that  contribute  to  key  design 
decisions  early  in  the  lifecycle  can  have  significant  impacts  on  costs,  schedule  and 
performance.  Currently,  there  is  no  true  mechanism  to  integrate  or  refine  the  models 
and  the  simulations  so  that  the  impact  to  the  system  can  be  seen  as  its  design  matures. 
The  ability  to  perform  W&A  early  in  the  modeling  process  and  throughout  the  lifecycle 
can  improve  the  model  and  its  contribution  greatly.  Having  a  precise  language  to  model 
systems  in  an  integrated  fashion  is  imperative  to  removing  ambiguity  and  the 
segmented  developmental  lifecycle. 


3  Objective 


The  objective  of  this  research  was  threefold: 

•  Explore  unique  capabilities  of  AADL  for  developing  high  confidence  (verified  and 
validated)  models  as  part  of  a  system  development  lifecycle. 

•  Create  a  test  bed  model  of  the  STIL’s  TSPI  data  to  understand  and  demonstrate 
how  W&A  can  be  embedded  into  the  development  of  architectural  model  using 
AADL. 

•  Determine  the  maturity  of  the  AADL  tools  for  W&A  model  refinement. 

AADL  can  support  W&A  by  using  a  standardized  foundation  for  the  Modeling  and 
Simulation  (M&S)  of  a  system.  This  research  is  the  beginning  step  in  showing  how 
verification  and  validation  time  can  be  reduced.  Verification  is  supported  by  the  AADL 
syntax  checker  and  analysis  tools  that  can  by  automated  to  find  known  potential 
problems  with  the  model.  Model  validity  is  supported  by  the  ability  to  use  the  same 
model  as  an  analysis  model  to  predict  system  performance  and  as  a  specification  of  the 
design  used  during  system  implementation.  The  implementation  of  the  system  should 
match  the  analysis  model  if  it  is  built  to  the  specifications. 

The  deliverables  from  this  research  were  the  following: 

1.  A  test  bed  built  and  provided  to  explore  how  development  times  could  be  reduced 
by  integrating  verification  and  validation  into  the  model  development  process  by 
using  the  AADL 

2.  A  demonstration  of  the  impacts  and  benefits  of  using  AADL  in  the  verification 
and  validation  process  including  the  ability  to  use  the  tools  on  DoD  designs  and 
determining  the  ability  to  migrate  toolsets  to  the  user  community  (learning  curve, 
challenges,  etc.) 
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4  Methodology 


AADL  was  chosen  for  this  research  task  because  AADL  provides  standardized,  well 
documented  semantics  to  underlay  tools,  enabling  ease  of  integration  of  tools  based  on 
AADL.  The  language  has  strong  semantics  and  textual  notation  that  enables  integration 
of  architecture  specifications  across  entities.  When  working  with  other  languages  the 
loose  or  weak  semantics  require  each  user  to  add  semantics  which  can  be  a  major  source 
of  errors,  inconsistencies,  and  undefined  assumptions.  AADL’s  well-formed 
architectural  behavior  semantics  cover  nominal  and  fault  management  behavior,  and 
allow  assessment  of  faulty  or  incomplete  models.  The  toolsets  have  the  ability  to 
provide  incremental  verification  and  validation  leading  to  a  qualified  system.  At  each 
stage,  starting  with  the  requirements,  we  can  validate  that  the  requirements  (and  then 
their  allocated  constraints  on  the  next  level)  are  sufficient  and  verify  the  correctness  of 
the  model  at  that  level.  The  ultimate  result  through  all  phases  of  verification  is  a 
qualified  system.1 

To  show  how  AADL  could  be  used  to  embed  the  Verification  and  Validation  of 
architectural  models  into  the  development  process,  an  architectural  model  of  the  STIL 
was  developed  and  used  as  a  test  bed.  The  following  process  was  followed: 

1.  Develop  a  conceptual  architectural  model  that  includes  the  logical  functional  blocks 
of  the  architecture,  relevant  performance  requirements,  and  traceability  to  the 
system  specification. 

2.  Verify  the  conceptual  architectural  model  by  using  automated  tools  to  verify  model 
semantics  and  completeness. 

3.  Develop  a  runtime  architectural  model  that  includes  the  software  and  execution 
platform  components  of  the  system,  relevant  properties  for  analysis,  and  traceability 
to  the  conceptual  architecture  model  and  to  the  sources  used  to  derive  values  in  the 
model. 

4.  Verify  the  runtime  architectural  model  by  using  automated  tools  to  verify  model 
semantics,  completeness,  and  whether  the  modeled  architecture  fulfills  performance 
requirements  specified  in  the  conceptual  architecture. 

5.  Validate  analyses  performed  on  the  architectural  models. 

6.  Continually  engage  the  stakeholders  in  an  iterative  manner  to  refine  the  research. 

Figure  5  shows  the  how  traceability  was  embedded  in  the  model  using  a  requirement 
from  the  STIL  System  Specification,  ASY-2526,  as  an  example. 
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Requirements  are  added  to  the  Conceptual  Model.  Properties  are  then  assigned  to  the 
Runtime  Model  allowing  traceability  to  the  methods  used  In  deriving  the  property  value  or 
source  of  the  information.  The  ability  to  trace  both  assumptions  and  data  inputs  to  their 
origin  provides  confidence  in  the  model  and  verification  of  the  model  and  architect. 


Figure  5:  Traceability  Process  Overview 


5.0  Research  and  Results 


The  architectural  model  of  the  STIL  was  developed  using  the  AADL.  The  Society  of 
Automotive  Engineers  (SAE)  standardizes  AADL  and  there  exists  an  assortment  of  tools 
available  to  work  with  it.  Version  l  of  the  AADL  was  used  during  this  task.  The 
following  tools  were  used  for  this  task: 

•  OSATE  -  An  Open-Source  AADL  development  environment  developed  by  the  SEI. 

•  Ocarina  -  A  tool  suite  for  working  with  AADL  models  developed  by  Telecom  ParisTech. 


5.1  Development  of  the  Conceptual  Architecture  Model 

The  modeling  process  began  with  the  creation  of  a  conceptual  architecture  model.  The 
conceptual  architecture  model  contained  the  high-level  functional  components  of  the 
STIL.  It  also  contained  a  specification  of  the  end-to-end  data  flow  through  the 
functional  components.  Due  to  time  and  funding  limitations,  the  focus  of  the  modeling 
was  on  the  elements  that  were  of  highest  priority  in  the  design  of  the  STIL.  The  element 
of  focus  was  related  to  the  TSPI.  A  graphical  representation  of  the  conceptual 
architecture  model  is  presented  in  Figure  6. 
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5.1.1  Conceptual  Elements 

In  order  to  model  the  conceptual  architecture  in  the  AADL,  a  custom  property  was  used 
to  designate  an  element  as  being  part  of  the  conceptual  architecture.  This  designation 
was  needed  in  order  to  differentiate  between  elements  of  the  runtime  and  the 
conceptual  architecture  during  automated  analysis.  The  custom  property  was  required 
because  version  l  of  the  AADL  does  not  support  this  capability.  Version  2  of  the  AADL 
features  an  "abstract"  component  type  that  addresses  this  shortfall  and  may  be  used  to 
model  conceptual  architectures  instead  of  using  a  custom  property. 


5.1 .2  Property  Traceability 

The  conceptual  architecture  model  contains  performance  requirements  specified  in  the 
system  specification  to  allow  for  the  analysis  of  the  modeled  architecture.  In  order  to 
aid  in  model  verification,  the  performance  requirements  need  to  be  traceable  to  the 
system  specification.  An  example  of  a  performance  requirement  is  the  maximum  latency 
of  the  end-to-end  flow  for  the  TSPI.  The  latency  property  in  AADL  was  used  to  specify 
the  maximum  allowed  latency.  In  order  to  embed  the  mapping  from  the  latency  value  to 
system  specification  a  new  property  was  introduced.  The  property  allows  the  modeler  to 
embed  references  to  the  requirements  in  the  system  specification  that  were  used  to 
derive  the  latency  value.  To  make  the  concept  generic,  the  idea  of  a  “shadow  property 
set”  was  introduced.  The  shadow  property  set  contains  properties  that  complement  the 
properties  in  the  main  property  set.  An  example  of  a  partial  shadow  property  set  is 
contained  in  Appendix  B.  Shadow  property  sets  and  their  properties  followed  a 
consistent  naming  scheme  designed  to  allow  usage  with  existing  property  sets  and 
automated  analysis. 


Figure  6  Graphical  Representation  of  the  Conceptual  Architecture  Model 


5.2  Verification  of  the  Conceptual  Architecture  Model 

The  conceptual  architecture  model  needed  to  be  verified  to  provide  confidence  that  it 
contained  the  necessary  information  for  the  desired  analysis  of  the  TSPI  data  flow. 
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The  AADL  specifies  rules  for  the  legality  of  units  and  property  assignments  based  on  the 
property  definitions.  AADL  tool  suites  such  as  OSATE  and  Ocarina  automatically  check 
the  model  to  ensure  these  rules  are  being  met.  This  helps  verify  the  model  does  not 
violate  the  semantics  of  the  language. 

Ocarina  contains  an  implementation  of  a  constraint  language  named  the  Requirement 
Enforcement  Analysis  Language  (REAL)  as  an  annex.  REAL  allows  an  AADL  modeler  to 
specify  constraints  that  can  be  checked  by  Ocarina.  REAL  was  used  to  help  verify  the 
conceptual  architecture  model  by  adding  constraints  to  check  if  performance 
requirements  were  specified  on  relevant  elements  and  that  those  requirements  were 
traceable  to  the  system  specification.  The  check  was  done  by  adding  REAL  constraints 
that  verified  the  existence  of  property  values  in  the  AADL  model.  In  general,  constraint 
languages  such  as  REAL  allow  specification  of  constraints  that  can  verify  the  model 
meets  custom  modeling  rules  and  to  check  for  known  potential  problems.  In  many 
cases,  these  constraints  can  be  shared  between  multiple  models.  Constraints  are 
especially  useful  with  the  handling  of  custom  property  sets;  they  allow  verification  of 
proper  usage  of  the  custom  properties. 

A  custom  OSATE  analysis  plugin  was  used  to  generate  a  requirements  traceability 
report  from  the  conceptual  architecture  model.  The  report  uses  the  requirement 
traceability  properties  to  generate  a  report  which  shows  the  traceability  between  the 
requirements  contained  in  the  system  specification  and  the  properties  in  the  conceptual 
architectural  model.  An  example  portion  of  a  generated  report  can  be  found  in  Appendix 
D. 


5.3  Development  of  the  Runtime  Architecture  Model 

In  order  to  analyze  the  flow  of  the  TSPI  through  the  system,  a  model  of  the  runtime 
architecture  model  was  developed.  The  runtime  architecture  model  was  based  on  the 
initial  Block  l  implementation  of  the  STIL.  While  the  components  of  the  conceptual 
architecture  model  corresponded  with  logical  functional  components  of  the  system, 
components  of  the  runtime  architecture  model  correspond  to  software  and  hardware 
components  of  the  system  implementation.  Some  of  the  types  of  components  it 
contains  are: 

•  Processes 

•  Processors 

•  Threads 

•  End  to  end  flow  specifications 

•  Buses 

•  Protocols 

Although  the  model  is  based  on  the  Block  l  implementation  of  the  STIL,  for  logistical 
reasons,  the  execution  platform  components  such  as  processors  and  buses  are  not 
reflective  of  the  STIL  block  l  implementation.  Rather,  it  is  representative  of  a  possible 
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hardware  configuration  of  the  system.  Two  versions  of  the  runtime  architecture  were 
modeled.  One  version  utilized  an  Ethernet  bus  for  communication  and  the  other 
utilized  a  reflective  memory  bus.  Both  versions  share  a  common  foundation  using  the 
refinement  mechanism  in  AADL.  The  hardware  configuration  is  shown  in  Figure  7 
where  “eth”  is  the  abbreviation  for  Ethernet,  and  “rm”  is  the  abbreviation  for  reflective 
memory. 


Figure  7  Hardware  portion  of  the  runtime  architecture  model 

The  software  components  of  the  model  directly  map  to  components  in  the 
implementation  of  the  STIL.  Figure  5  shows  the  three  processes  involved  with  the 
generation  and  transfer  of  TSPI  data  to  the  System  Under  Test  (SUT). 
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Figure  8  Top  level  of  the  software  portion  of  the  runtime  architecture  model 
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5.3.1  Traceability  to  the  Conceptual  Architecture  Model 

Elements  of  the  runtime  model  needed  to  be  traceable  to  the  conceptual  model  to  allow 
traceability  from  the  system  specification  to  the  runtime  model  and  to  allow 
performance  requirements  found  in  the  conceptual  architecture  model  to  be  accessible 
when  analyzing  the  runtime  architecture  model.  The  traceability  aids  in  verifying  that 
the  runtime  architecture  model  reflects  the  conceptual  architecture.  The  traceability 
was  embedded  into  the  model  by  using  custom  properties  to  map  elements  in  the 
runtime  model  to  elements  in  the  conceptual  architecture  model.  The  custom  property 
set  is  contained  in  Appendix  C.  Another  method  of  mapping  between  the  conceptual 
architecture  to  the  runtime  architecture  is  the  refinement  mechanism  found  in  the 
AADL.  Both  of  these  techniques  are  described  in  version  2  of  the  AADL  standard. 
Properties  were  used  to  specify  the  mapping  to  allow  for  added  flexibility  by  allowing  a 
single  runtime  component  to  potentially  be  traceable  to  multiple  conceptual 
components. 


5.3.2  Tracing  Property  Values  to  Origin 

When  modeling  a  system,  values  entered  as  part  of  the  model  can  derived  in  a  number 
of  different  ways,  e.g.  estimation,  calculation,  and  measurements.  In  AADL  these  values 
become  property  values.  The  method  used  to  obtain  a  property  value  is  important  in 
order  to  gain  confidence  in  the  model.  Custom  properties  were  used  to  denote  the 
method  used  to  obtain  the  property  values  contained  in  the  runtime  architecture  model. 
The  property  values  were  contained  in  the  same  shadow  property  sets  used  to  trace 
performance  requirements  to  the  system  specification.  An  example  property  set  can  be 
found  in  Appendix  B.  Embedding  the  derivation  method  into  the  model  promotes 
model  reuse  because  other  users  of  the  model  have  information  needed  to  ensure  that 
the  model  is  appropriate  for  the  intended  use. 


5.4  Verification  of  the  Runtime  Architecture  Model 

Various  automated  analyses  were  performed  on  the  runtime  architecture  model  in  order 
to  verify  that  it  contained  needed  information  and  met  the  performance  requirements 
specified  in  the  conceptual  architectural  model.  The  precise  semantics  of  AADL 
supports  automated  verification  efforts  by  allowing  multiple  tools  to  work  on  a  single 
model  based  on  a  common  understanding.  An  OSATE  plug-in  was  used  to  check  the 
consistency  of  the  binding  of  port  connections  to  the  execution  platform  components. 
The  plug-in  was  used  to  verify  that  the  connections  specified  in  the  model  were 
semantically  valid.  REAL  was  used  to  ensure  the  existence  of  properties  for  the  tracing 
to  the  conceptual  architecture  model  and  the  derivation  method  of  property  values.  It 
was  also  used  to  ensure  the  existence  of  properties  needed  for  other  analysis  and  to 
verify  that  all  threads  were  bound  to  a  processor. 

Several  reports  were  generated  from  the  architectural  model  as  a  method  of  generating 
artifacts  showing  the  traceability  built  into  the  model.  This  could  also  be  beneficial 
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when  looking  at  accrediting  a  system.  The  Conceptual  to  Runtime  Traceability  Report 
shows  the  relationship  between  the  runtime  and  the  conceptual  architecture  models. 
The  Derivation  Method  Report  contains  properties  found  in  the  runtime  architecture 
model  and  the  method  used  to  derive  their  values.  Example  portions  of  the  reports  can 
be  found  in  Appendix  D. 

Communication  analysis  was  performed  in  order  to  determine  the  performance 
characteristics  of  the  modeled  system.  The  automated  analyses  used  the  runtime 
architectural  model  to  calculate  the  bandwidth  usage  and  the  latency  of  the  end-to-end- 
flows  specified  in  the  system.  This  calculation  was  done  in  a  custom  OSATE  analysis 
plugin.  The  end-to-end  flow  latency  was  calculated  using  the  method  described  in  the 
SEI  Technical  Note,  Flow  Latency  Analysis  with  the  Architecture  Analysis  and  Design 
Language  (AADL).  The  analysis  utilized  the  traceability  from  the  runtime  architecture 
model  to  the  conceptual  architecture  model  to  retrieve  performance  requirements.  The 
analysis  tool  helps  to  verify  that  the  design  of  the  system  meets  the  requirements 
specified  in  the  conceptual  architecture  by  comparing  the  required  maximum  latency 
with  the  calculated  maximum  latency.  The  analysis  can  be  applied  iteratively.  As  more 
detail  is  added  to  the  architectural  model,  the  analysis  generates  more  precise  results 
therefore  illustrating  incremental  verification  and  validation.  The  analysis  generated  a 
bandwidth  and  latency  report.  Examples  of  the  reports  can  be  found  in  Appendix  D. 


5.5  Validate  Analyses 

Models  and  analysis  must  be  validated  in  order  to  ensure  that  results  reflect  the 
modeled  system  to  enough  of  a  degree  to  be  used  for  the  desired  purpose. 

A  code  generation  technique  was  used  to  demonstrate  how  an  analysis  and  architectural 
runtime  model  could  be  validated  early  in  the  development  process.  The  latency  portion 
of  the  communication  was  used  for  the  demonstration.  To  generate  data  to  compare 
against,  a  code  generator  was  used  to  generate  C  code  based  on  the  runtime 
architectural  model.  A  program  was  generated  for  each  process  specified  in  the  runtime 
architecture  model.  The  generated  code  was  executed  in  a  lab  setup  that  reflected  the 
hardware  described  in  the  runtime  architecture  model.  The  generated  programs 
exchanged  data  at  the  correct  rates  and  used  the  data  structures  described  in  the 
architecture  model.  The  programs  also  generated  log  files  that  were  post -processed  in 
order  to  generate  a  report  containing  the  calculated  latency  of  the  end-to-end  flows  in 
the  running  system.  The  generated  report  is  shown  in  Appendix  D.  The  results  of  the 
validation  effort  showed  that  in  3  out  of  the  4  runs,  the  measured  values  were  within  the 
expected  range.  In  one  run,  the  maximum  latency  was  greater  than  the  calculated 
worst-case  latency.  It  is  believed  it  was  caused  by  the  lack  of  a  precise  time 
synchronization  technique.  Further  analysis  would  be  required  to  come  to  a  conclusion 
of  the  root  cause. 
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5.6  Briefings  to  the  Stakeholders 

Throughout  the  research  task  RSESC  continually  engaged  the  stakeholders  in  an 
information  and  feedback  exchange  to  refine  the  approach  and  to  ensure  it  was  meeting 
the  goals  of  all  the  stakeholders.  RSESC  worked  to  bridge  the  gap  between  fundamental 
and  applied  research  in  order  to  transfer  this  knowledge  to  the  user  community.  It  was 
a  goal  to  ensure  that  the  results  from  this  task  not  only  benefited  the  W&A  community 
but  also  the  user  community.  The  meetings  were  done  both  formally  and  informally 
with  PEO-STRI/PM-ITTS,  the  Army’s  Flight  Test  Directorate  under  the  Redstone  Test 
Center,  AMRDEC’s  AED,  AMRDEC’s  SED,  the  AADL  User’s  group  leaders  and  SAVI 
leaders. 

The  final  out  briefing  for  the  W&A  task  occurred  in  Huntsville,  Alabama  on  January  20, 
2011.  It  was  a  two  day  event  and  began  with  Phil  Zimmerman  briefing  at  the  American 
Helicopter  Society’s  Huntsville  Chapter  monthly  technical  luncheon  meeting  about  the 
W&A  initiatives.  After  the  luncheon,  UAHuntsville  RSESC  researchers  and  the 
sponsors  of  UAHuntsville’s  research  task,  PEO-STRI/  PM-ITTS  and  Office  of  the 
Secretary  of  Defense,  toured  the  Redstone  Test  Center’s  STIL  facility. 

The  attendees  list  and  agenda  for  the  visit  is  provided  in  Appendix  E. 


6  Overall  Research  Findings 


A  primary  objective  was  to  explore  the  unique  capabilities  of  AADL  for  developing  high 
confidence  (verified  and  validated)  models  as  part  of  a  system  development  lifecycle.  To 
meet  this  objective,  RSESC  created  a  test  bed  model  of  the  STIL’s  TSPI  data  to 
understand  and  demonstrate  AADL’s  capability  in  regards  to  incremental  W&A. 

The  research  shows  that  the  AADL  language  forces  the  model  to  conform  to  a  set  of 
rules  which  help  verify  the  model.  Having  a  standardized  model  of  the  system  allows 
analyzing  the  model  to  find  potential  problems.  AADL’s  extensible  nature  is  useful  for 
enhancing  overall  capabilities  and  aids  in  the  verification  and  validation  of  architectural 
models  created  in  it.  Custom  annexes  allow  sublanguages,  such  as  REAL,  to  be 
embedded  within  the  model  for  verification  purposes.  AADL’s  well-defined  semantics 
do  support  Architecture/System  Design  verification  by  allowing  a  precise  specification 
of  the  architecture  so  that  the  analysis  performed  on  it  is  trustworthy  and  repeatable. 
AADL’s  ability  to  use  custom  property  sets  allows  the  embedding  of  traceability 
information  into  the  model.  The  traceability  data  then  aids  in  the  verification  of  values 
contained  in  the  model. 

This  objective  was  met  by  successfully  modeling  the  flow  of  the  TSPI  data  in  the  STIL  as 
well  as  modeling  Ethernet  and  reflective  memory  variations  of  the  system  architecture. 
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By  modeling  the  STIL,  clear  evidence  was  found  as  to  the  value  of  using  a  model  based 
engineering  languages  such  as  AADL. 

It  was  previously  thought  that  the  primary  contributor  to  latency  and  jitter  on  the  STIL 
was  the  bus  used  for  communication.  RSESC  was  able  to  determine  through  that  in  the 
case  of  the  STIL,  the  usage  of  globally  asynchronous  threads  along  with  data  sampling 
was  the  primary  contributor  to  latency  and  jitter.  This  analysis  was  done  through 
incrementally  verifying  and  validating  the  model.  Further,  it  was  determined  that  the 
lack  of  synchronization  and  the  usage  of  data  sampling  cause  significant  latency  because 
threads  will  not  consume  new  data  until  the  thread  period  after  the  data  is  produced. 

AADL  did  prove  to  have  multiple  strengths.  First,  there  are  significant  amount  of 
resources  concerning  AADL  on  the  internet  that  include  examples,  wiki,  and  scholarly 
papers.  Secondly,  copies  of  the  AADL  standard  are  available  from  the  SAE.  And  lastly, 
it  is  reasonably  easy  to  learn  for  someone  with  knowledge  of  software  systems. 

On  the  other  side  were  the  weaknesses.  The  toolsets  had  some  maturity  issues  in  several 
different  areas.  At  the  time  of  the  research  effort,  the  current  stable  version  of  OSATE 
does  not  support  AADL  V2  and  lacked  a  mature  graphical  editor.  Ocarina  does  support 
AADL  V2  but  with  limitations.  There  were  minor  issues  concerning  AADL  terms  which 
are  slightly  different  than  existing  terms.  The  usage  was  understandable  and  defined  in 
the  AADL  standard,  though  time  was  required  to  learn  nuances.  But  by  using  version  1 
of  AADL  many  of  these  weaknesses  were  overcome  and  good  results  were  found  for  the 
overall  STIL  design. 


7  Conclusion 


RSESC  was  able  to  illustrate  the  usability  of  AADL  in  a  very  short  research  task.  It  was 
shown  that  a  portion  of  a  real  world  DoD  representative  system  could  be  modeled  using 
AADL  in  a  very  short  time  with  little  knowledge  of  AADL.  Valuable  feedback  was  given 
to  PEO-STRI  in  the  development  of  the  STIL  in  regards  to  latency  of  the  Ethernet  verses 
reflective  memory  of  the  system. 

UAHuntsville  RSESC  completed  all  of  the  following  tasks  in  less  than  six  months: 

•  Clearly  defined  a  task  that  supported  the  effort 

•  Selected  a  system  to  model 

•  Worked  in  coordination  with  the  AADL  Users  Group,  SAVI  and  PEO-STRI 

•  Designed  and  developed  the  model 

•  Applied  real  world  DoD  system  specifications  to  the  model 

•  Learned  AADL  and  its  caveats 
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•  Refined  knowledge  of  W&A  and  M&S 

•  Wrote  open  source  code  to  address  software  maturity  issues 

•  Came  up  to  speed  and  used  OSATE  and  Ocarina  analysis  tools  as  well  as 
developed  other  analysis  tools  to  complete  the  analysis 

•  Validated  the  results  of  the  analysis  by  generating  code  from  the  model  and 
running  it 

From  this  research  the  benefits  of  using  AADL  were  seen  including  the  ability  to 
perform  incremental  W&A  on  system  architectures,  perform  trade  studies  on  crucial 
components  of  the  system  and  to  discern  deep  architectural  issues.  AADL  can  detect 
design  or  requirement  problems  related  to  the  integration  of  the  system  and  system 
level  qualities  while  considering  the  impact  on  system  reliability  and  safety. 

Long  term  benefits  include  the  ability  to  reduce  overall  costs  as  found  in  the  SAVI  costs 
benefits  study.  The  first  aircraft  program  to  apply  SAVI  saved  in  the  worst  case  $700 
million  up  to  the  best  case  of  $2  billion.  Expanding  the  same  philosophy  using  AADL  in 
the  M&S  community  could  help  save  additional  money.  And  lastly,  expanding  the 
research  to  partner  with  the  US  Army’s  Research,  Development  and  Engineering 
Command  (RDECOM),  AMRDEC,  System-Simulation-and  -Development-Directorate 
facilities  or  the  Joint  Technology  Center/Systems  Integration  Laboratory  to  explore  how 
or  if  AADL  could  be  further  utilized  to  fill  W&A  gaps  for  simulations. 

When  looking  at  the  benefits  to  the  stakeholders,  many  benefits  can  be  foreseen. 
Developers  of  complex  software-reliant  systems  could  lower  development  costs  by 
building  more  effective  systems  thus  saving  money  to  the  taxpayer.  Modeling  systems 
in  a  precise  design  language  could  allow  the  DoD  the  ability  to  rapidly  build  and  add 
flexibility  to  its  systems,  which  in  turn  would  maintain  the  leadership  role  it  enjoys  in 
fields  like  aerospace.  This  technique  in  turn  could  be  shared  with  other  fields  that  use 
M&S  for  safety  critical  and  complex  systems  as  well  as  with  the  acquisition  community 
and  stakeholders  involved  with  M&S  and  system  development.  Successful  research 
would  allow  for  new  methods  and  knowledge  on  incremental  W&A  and  how  it  might 
integrate  into  an  overall  process  including  virtual  integration  and  enhanced  use  of 
qualified  SILs  and  STILs.  This  research  expands  on  existing  SAVI  and  AADL  research 
in  the  area  of  incremental  verification  and  validation  using  the  AADL  language  to 
demonstrate  benefits  for  future  and  existing  systems.  Lastly  furthering  this  concept  on 
real  DoD  systems,  could  provide  a  foundation  of  new  methods  and  ideas  for  the  M&S 
community,  the  system  development  community,  Project  Managers  and  the  students, 
our  future  designers  and  developers. 
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8  Recommendations 


For  this  task  interested  parties  from  several  disciplines  that  see  value  in  the  overall 
modeling  of  a  system  were  brought  together.  Participation  in  this  research  task  came 
from  several  communities,  the  flight  test  community,  system  developers,  users, 
simulation  community,  the  Army’s  AMRDEC  AED  that  is  in  charge  of  flight  worthiness 
and  the  Army’s  AMRDEC  SED.  As  future  phases  for  this  task  unfold,  the  realization  of 
breaking  down  the  barriers  to  use  one  model  or  slight  variations  of  a  similar  model  to 
perform  multiple  tasks  for  system  development  should  be  viable. 

One  recommendation  for  a  follow  on  to  this  research  would  begin  to  look  at  the 
possibility  of  overlaying  planned  TCD  efforts  of  a  program  with  a  Model  -  Based 
Engineering  (MBE)  process,  including  three  stages  which  correspond  to  three  S&T 
acquisitions: 

1.  Overlay  Configuration  Trades  and  Analysis  with  Conceptual  Model  Development. 

2.  Overlay  Air  Vehicle  Development  with  M&S  Development,  including  constructive 
simulations  and  reconfigurable  virtual  prototypes. 

3.  Overlay  Mission  System  Development  with  Model  Instances  in  System/Software 
Integration  Labs  (SIL). 

Using  this  approach  for  programs  will  make  the  requirements  more  consistent  and 
traceable,  and  will  allow  for  more  exploration  of  design  solutions  using  the  model  and 
correlated  simulation  tools.  Having  such  a  precise  model  will  link  the  architectures  of 
the  system,  the  simulations,  and  the  SILs  for  rapid  airworthy  code  development  and 
qualification  which  will  have  a  significant  impact  in  reducing  development  costs.  As  a 
result,  the  effort  will  shift  into  designing  adaptable  systems  rather  than  evaluating  point 
solutions.  Using  MBE  will  also  allow  the  system  design  to  be  built  upon  from  many 
different  areas  of  expertise  and  result  in  a  singular  truth  representation  -  thereby 
avoiding  sole  reliance  on  competing  and  often  incompatible  proprietary  design 
documents.  MBE  will  further  break  down  stovepipes  between  the  respective 
communities  of  design,  performance  evaluation,  and  qualification.4 

Continue  expanding  the  STIL  model  to  further  demonstrate  benefits  and  weakness: 

•  Model  potential  connections  between  the  Virtual  Prototyping  Model  and  the 
Redstone  Test  Center  (RTC)  STIL  to  demonstrate  System  of  Systems  integrated 
flight  of  Joint  Multi  Role  (JMR)  with  current  platforms  and  enable  transition  of 
virtual  designs  to  operational  software. 

•  Demonstrate  the  ability  to  expand  the  existing  model  to  system  testers  and  merge 
models  from  other  sources  while  performing  incremental  W&A. 

•  Integrate  the  STIL  model  with  the  AADL  helicopter  model  that  is  in  development 
by  SEI  and  the  AADL  users  group  to  demonstrate  end-to-end  modeling 
capability. 


Report  No.  SERC  201 1  -TR-01 8 
May  3,  201 1 

UNCLASSIFIED 

25 


Contract  Number:  H98230-08-D-0171 


DO002,  TO002,  RT021 


UNCLASSIFIED 


•  Compare  the  communication  analysis  results  with  Block  l  STIL  communication 
characteristics  to  validate  the  model  and  the  analysis. 

•  Presently  working  with  Wayne  State  University  and  TARDEC  on  Platform-  Based 
Engineering  and  Model-Based  Engineering  to  expand  and  explore  possible 
benefits  to  Ground  PMs  and  Aviation  PMs.  . 

•  Questions  to  consider: 

-  Can  AADL  help  in  building  a  system  that  allows  flexibility,  versatility  while 
preserving  V&V  already  performed  on  the  system  or  model? 

-  How  can  AADL  help  in  modeling  legacy  systems? 

-  Are  there  techniques  (Methods,  Processes  and  Tools)  that  are  being 
utilized  by  the  JMR  project  that  could  be  beneficial  to  ground  systems? 

Virtual  Prototyping  of  JMR  Army  Rotorcraft  or  the  Future  Vertical  Lift  Initiative 

•  Use  virtual  prototyping  as  a  means  to  reduce  risk  in  design  of  JMR.  (Combined 
submission  from  SSDD,  SED,  AED,  and  UAHuntsville) 

•  Use  AADL  to  develop  a  conceptual  model  of  JMR  (UAHuntsville  effort  in 
conjunction  with  AED  and  SED) 

•  Implement  the  model  in  the  development  of  a  cockpit  simulator  in  the  SSDD 
APEX  2  lab,  incorporating  the  AED  flight  model. 

•  Link  virtual  cockpit  through  distributed  simulation  to  the  SED  SIL/ASIF. 


In  summary,  based  on  the  positive  results  found  during  this  research,  a  number  of 
future  research  areas/tasks  are  available: 

•  Models  as  specs 

•  Model-based  design  documentation 

•  Platform  based  engineering 

•  Incremental  and  adaptable  verification  and  validation  of  systems  and  simulations 

•  Auto-generation  of  test  plans  and  reports 

•  Trusted  evidence  generated  using  tools/automation 

•  Expansion  of  the  research  into  utilizing  the  same  tool  to  perform  incremental 
verification  and  validation  of  systems  and  simulations  to  leverage  models, 
systems  engineering  processes  and  the  V&V  process 
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Appendices 


Appendix  A  References 

1.  The  sections  noted  with  a  footnote  l  within  the  final  report  were  written  using  the 
following  reference  papers  and  presentations  and  during  informal  discussions 
with  the  individuals  listed  below.  This  work  is  an  extension  of,  and 
complimentary  to,  the  on-going  research  tasks  of  the  AADL  users  group  and 
SAVI  project. 

Referenced  Papers  and  Presentations: 

a.  The  SAE  Architecture  Analysis  &  Design  Language  (AADL) 
Standard,  Peter  H.  Feiler,  Software  Engineering  Institute,  January  2008. 

b.  Challenges  in  Validating  Safety-Critical  Embedded  Systems,  Peter 
H.  Feiler,  Software  Engineering  Institute,  Copyright  ©  2009  SAE 
International,  09ATC-0271. 

c.  Diagrams  and  Languages  for  Model-Based  Software  Engineering  of 
Embedded  Systems:  UML  [Unified  Modeling  Language]  and  AADL, 
Dionisio  de  Niz,  Software  Engineering  Institute,  Carnegie  Mellon. 

d.  Multi-Dimensional  Model  Based  Engineering  for  Performance 
Critical  Computer  Systems  Using  the  AADL,  B.  Lewis,  P.  Feiler, 
Proceedings  from  Embedded  Real  Time  Software  and  Systems  ( ERTS 2),  25-27 
January  2006,  Toulouse. 

e.  System  Architecture  Virtual  Integration:  A  Case  Study,  P.  Feiler,  L. 
Wrage,  J.  Hansson.  Proceedings  from  Embedded  Real  Time  Software  and 
Systems  (ERTS2)  2010. 

f.  Flow  Latency  Analysis  with  the  Architecture  Analysis,  Peter  H.  Feiler, 
Jorgen  Hansson,  Carnegie  Mellon  University  Software  Engineering 
Institute,  Technical  Note,  CMU/SEI-2007-TN-010,  December  2007. 

Individual  Contributions  by: 

a.  Dr.  Bruce  Lewis,  US  Army  RDECOM,  AMRDEC,  Software  Engineering 
Directorate. 

b.  Dr.  Dave  Redman,  Aerospace  Vehicle  Systems  Institute  (AVSI),  Texas  A&M 
University. 

c.  Dr.  Don  Ward,  Aerospace  Vehicle  Systems  Institute  (AVSI),  SAVI  Program, 
Texas  A&M  University. 

2.  The  sections  noted  with  a  footnote  2  within  the  final  report  were  written  using 
the  following  reference  papers  and  presentations  provided  by  AVSI  and  during 
informal  discussions  with  the  following  listed  individuals. 

Referenced  Papers  and  Presentation: 
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The  SAE  Architecture  Analysis  &  Design  Language  (AADL)  Standard, 

Peter  H.  Feiler,  Software  Engineering  Institute,  January  2008. 

Individual  Contributions  by: 

a.  Dr.  Bruce  Lewis,  US  Army  RDECOM,  AMRDEC,  Software  Engineering 
Directorate. 

b.  Dr.  Dave  Redman,  Aerospace  Vehicle  Systems  Institute  (AVSI),  Texas  A&M 
University. 

c.  Dr.  Peter  Feiler,  Software  Engineering  Institute,  Carnegie  Mellon  University. 

d.  Dr.  Don  Ward,  Aerospace  Vehicle  Systems  Institute  (AVSI),  SAVI  Program, 
Texas  A&M  University. 

3.  The  sections  noted  with  a  footnote  3  within  the  final  report  were  written  using 
the  following  reference  papers  and  presentations  provided  by  PEO-STRI/PM- 
ITTS  and  during  informal  discussions  with  by  PEO-STRI/PM-ITTS  and  the  Army 
RTC. 


4.  The  sections  noted  with  a  footnote  4  within  the  final  report  were  written 
referencing  the  Director,  Defense  Research  and  Engineering  (DDRE)  Systems 
2020  RFI,  entitled  "Model-Based  Engineering  (MBE)  of  Joint  Multi-Role  (JMR) 
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Appendix  B  Shadow  Property  Set  for  AADL  Properties 

property  set  aadl_propert ies_traceability  is 

—  Tracing  to  requirements 
Latency_Requirements :  list  of  aadlstring 

applies  to  (flow,  connections,  1ms) ; 

Per iod_Requirements :  inherit  list  of  aadlstring 

applies  to  (thread,  thread  group,  process,  system,  device) ; 

—  Derivation  Methods 

Compute_Execut ion_Time_Der ivat ion_Method :  aadlString 

applies  to  (thread,  device,  subprogram,  event  port,  event  data  port,  data  port) ; 
Tr  ansm i s  s i o  n_T ime_D  e  r ivat i o  n_Me  t  ho  d :  aadlS t  r ing 
applies  to  (bus) ; 
end  aadl_propert ies_traceatiility; 


Appendix  C  Conceptual  Properties 

property  set  conceptual_propert ies  is 

—  Used  to  mark  an  element  as  part  of  the  conceptual  architecture 
Conceptual:  inherit  aadlhoolean  =>  false 
applies  to  (all) ; 

--  Allows  a  runtime  end  to  end  flow  to  be  associated 
--  with  a  conceptual  end  to  end  flow 
C  o  nc  e  p  t  ua 1_E  nd_To_E  nd_F 1 o  w_Owne  r :  refer  enc  e 
applies  to  (flow) ; 

Conceptual_End_To_End_Flow_Name :  aadlstring 
applies  to  (flow) ; 

--  Associates  a  runtime  component  and  its  children  with  a 
--  conceptual  component. 

Conceptual_Component :  inherit  list  of  reference 
applies  to  (process,  thread,  bus) ; 

end  conceptual_propert ies; 


Contract  Number:  H98230-08-D-01 71  DO002,  TO002,  RT021 

Report  No.  SERC  201 1  -TR-01 8 
May  3,  201 1 

UNCLASSIFIED 

29 


UNCLASSIFIED 


Appendix  D  Reports 
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Figure  9  Conceptual  to  Runtime  Traceability  Report 


Figure  10  Derivation  Method  Report 
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Figure  11  Latency  Analysis 
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Figure  12  Latency  Measurement  Report 
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All  other  figure-  and  table-type  items  are  included  as  Slides  from  an  extended  version  of  the 
final  out-brief  presentation  (in  four  parts  totaling  ~ 175 +  slides). 
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1  Introduction  &  Context 


1.1  Context 

The  US  Dept,  of  Defense  (DoD)  Systems  Engineering  Directorate  in  the  Director,  Defense 
Research  and  Engineering  (DDR&E)  organization  initiated  SERC  Research  Topic  21  (RT21)  in 
the  2010  3rd  quarter  time  frame.  RT21  is  entitled  “Verification,  Validation  and  Accreditation 
(W&A)  Shortfalls  for  Models  &  Simulations  (M&S)”  and  is  aimed  at  the  following  overall  needs 
as  described  by  the  sponsor  : 


W&A  activities  for  models  and  simulations  are  conducted  across  government,  academia,  and 
industry,  both  within  the  U.S.  and  internationally.  In  the  DoD,  the  responsibility  for  W&A 
exists  at  various  organizational  levels.  With  the  recent  revision  to  DoDI  5000.61  and  past  DoD- 
funded  technical  studies  such  as  the  “Risk  Based  Assessment”,  the  update  to  the  W&A 
Recommended  Practices  Guide  (RPG),  and  the  DoD  W&A  Documentation  Templates  as 
defined  in  MIL-STD  3022,  steps  have  been  taken  to  support  more  efficient  and  effective  W&A 
implementation.  While  these  efforts  have  addressed  known  W&A-related  gaps, 
implementation  of  W&A  practices  appears  to  remain  uneven,  sporadic,  or  ad  hoc.  W&A 
research  needs  to  focus  on: 

1)  Users  in  the  field,  e.g.,  Program  Managers  and  contractors,  to  better  understand  the  gaps 
related  to  W&A  from  their  perspective. 

2)  Technical  opportunities  to  address  W&A  of  a  federation  comprised  of  models  and 
simulations  based  on  3  different  perspectives: 

a)  The  model/simulation  operating  as  stand-along  capabilities  (single  instances). 

b)  The  individual  model/simulation  when  federated  (linked)  with  other  M&S  capabilities. 

c)  The  collective  capability  of  M&S  assets  when  operating  as  a  federation. 

This  is  analogous  to  the  test  and  evaluation  (T&E)  challenges  of  doing  single  system 
evaluation  at  the  same  time  assessing  its  role/capability  as  part  of  a  system  of  systems  - 
and  of  the  system  of  systems  as  a  whole. 

3)  Methods,  processes  and  tools  to  address  ad  hoc  and  sporadic  implementation  of  W&A,  for 
example,  methods  to  improve  W&A  to  better  characterize  M&S  risks  prior  to  testing. 

4)  Recommendations  to  minimize  the  risk  of  erroneous  representations  due  to  incomplete  or 
inadequate  W&A. 

5)  Enterprise  level  efforts  that  can  improve  W&A  implementation  across  the  DoD. 

6)  Technology,  method,  process  or  tool  opportunities  to  advance  the  DoD’s  capabilities  to 
perform  W&A. 


As  part  of  the  RT21  team,  our  Georgia  Tech  effort  in  this  initial  phase  explored  how  to  address 
many  of  these  needs  using  a  SysML  model-based  approach. 
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1 .2  Objectives  and  quick-look  approach 

Given  the  needs  and  challenges  described  by  the  sponsor  above,  the  Georgia  Tech  primary 
objective  in  RT21  has  been  this: 

•  Demonstrate  how  to  address  W&A  gaps  by  applying  SysML  and  MBE/MBSE  technology 
(especially  showing  how  V&V  can  be  more  embedded  and  automated  throughout  system 
lifecycle). 

Our  supporting  sub-objectives  have  been  to  do  the  following: 

•  Apply  known  M&S  patterns  and  develop  new  patterns  where  needed. 

•  Demonstrate  our  approach  by  extending  existing  testbeds  and  examples  (e.g.,  a  excavator 
testbed  (Figure  1  and  Figure  2),  a  mobile  robotics  testbed,  and  other  examples). 

•  Provide  a  basis  (i)  for  developing  DoD-specific  testbeds  and  extensions  in  future  phases  and 
(ii)  for  deploying  this  technology  for  DoD  programs. 

Per  sponsor  request  we  have  used  a  “quick-look”  approach  in  this  project  to  give  the  sponsor  a 
brief  broad  overview  how  this  technology  can  address  their  W&A  needs.  Therefore,  we  use  an 
extended  version  of  the  final  out-brief  presentation  as  the  primary  content  for  this  report  and 
only  briefly  describe  selected  slides  here.  We  recommend  future  project  phases  to  explore  and 
demonstrate  at  least  some  of  these  topics  in  more  depth  depending  on  sponsor  priorities. 
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Figure  l  -  Excavator  testbed  modeling  &  simulation  environment.  [Peak  et  al.  2008/2009] 
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(b)  Model  interoperability  method  (MIM)  patterns  view  (architecture  view  per  CT-16). 
Figure  1  -  Excavator  testbed  modeling  &  simulation  environment.  [Peak  et  al.  2008/2009]  (cont.) 


1.3  Report  structure 

The  extended  final  out-brief  presentation  is  divided  into  Parts  1-4  and  attached  as  the  primary 
content  of  this  report.  Each  section  of  this  report  describes  the  corresponding  Part  of  the 
extended  presentation  (i.e.,  the  rest  of  Section  1  covers  the  Part  1  slides,  Section  2  covers  the  Part 
2  slides,  and  so  on). 

We  reference  the  presentation  slides  here  in  the  text  (instead  of  including  them  as 
figures)  using  a  “Slide  p-n”  notation  per  the  slide  numbering  in  the  lower  right  corner  (where  p 
is  the  part  number  and  n  is  the  slide  number  within  that  part).  In  Section  3  below  (which  covers 
presentation  Part  3)  we  additionally  use  a  “Slide  CT-c-n”  notation  where  c  is  the  concept  number 
(described  in  Section  3)  and  n  is  the  slide  number  within  that  concept  subsection. 
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Figure  2  -  Excavator  testbed:  sample  SysML  diagrams  and  native  solver  models. 


1 .4  Project  process  and  technical  approach 

We  have  approached  the  W&A  problem  with  a  hybrid  bottom-up/top-down  philosophy— one 
that  envisions  building  blocks  for  W&A  which  enable  W&A  activities  to  be  ubiquitous  and 
iterative  to  the  degree  that  they  become  near-continuous.  We  believe  software  V&iV  techniques 
(including  continuous  integration1  technologies  and  test-based  design  tools  like  JUnit2)  can  be 
generalized  and  applied  to  systems  development. 

Applying  the  Papa  John’s  philosophy  of  “Better  Ingredients,  Better  Pizza”  philosophy 
(Slide  l-ll),  we  hold  that  to  get  good  M&S  (and  ultimately  good  systems),  you  must  use  good 
M&S  ingredients.  Hence,  from  a  W&A  perspective,  that  means  applying  V&V  from  bottom  to 
top— from  the  lowest-level  M&S  component  to  the  highest-level  simulation  system— and  to  all 


1  See  http: / /en.wikipedia.org/wiki/ Continuous  integration  and  tools  like  Bamboo  (www.atlassian.comk 

2  See  www.iunit.org. 
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M&S  subsystems  in  between.  It  is  with  this  philosophy  that  we  have  both  pursued  this  RT21 
effort  and  organized  the  this  final  report. 

Per  sponsor  guidance  we  are  leveraging  existing  examples  from  our  previous  work  where 
feasible.  Rather  than  building  new  DoD-based  test  cases  in  this  phase,  we  are  illustrating  the 
technical  approach  in  quick-look  fashion  with  existing  test  cases  from  a  variety  of  domains.  We 
started  by  adding  W&A-oriented  extensions  where  needed  per  Activity  2  in  our  project  plan 
(Slide  1-12).  Then  in  Activity  3  (Slide  1-13)  we  performed  additional  extensions  and  created  new 
examples  in  order  to  fill  out  a  sample  spectrum  of  W&A  use  cases  along  multiple  system 
dimensions  (including  a  diversity  of  system  levels,  tools,  methods,  and  lifecycle  phases).  Each  of 
the  resulting  concepts  and  examples  are  covered  in  Section  3. 


1.5  SysML  AND  MBE/MBSE  CONTEXT 

Slide  1-14  onward  gives  a  quick  introduction  to  SysML  and  the  MBE/MBSE  approach.  These 
slides  also  highlight  our  project  testbed  experiences  from  other  projects  and  our  related  short 
courses.  Section  2  covers  additional  background  material  as  prerequisite  for  better 
understanding  the  concepts  in  Section  3. 


1 .6  Target  impact 

We  conclude  the  [Part  1]  project  overview  presentation  with  these  “impact  questions”  from  the 
SERC  project  proposal  template  (which  is  based  on  the  Heilmeier  program  definition 
questions): 

Ql:  Who  should  care?  Al:  All  M&S  and  W&A  stakeholders  (given  benefits  below). 

Q2:  If  you're  successful,  what  difference  will  it  make?  A2:  See  benefits  table  in  Slide  1-27. 
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2  SysML  Concepts:  Essential  Prerequisites 


These  Part  2  slides  cover  essential  SysML  concepts  including  how  SysML  supports  MBE  in 
general  and  MBSE  in  particular  (building  on  the  introductory  slides  included  in  Part  l).  These 
concepts,  which  are  necessary  prerequisites  for  understanding  the  rest  of  this  report,  are 
grouped  together  in  these  Part  2  slide  set  subsections: 

•  SysML  context:  system  modeling  &  general  modeling 

•  Representative  SysML  authoring  tool  (MagicDraw) 

•  Blocks  and  instances 

•  Blocks  and  equation-based  knowledge:  parametrics 

o  DNA  signatures  (described  further  in  Section  3  CT-ll) 

•  Other  concepts  covered  in  later  Parts  as  needed: 

o  Requirements  representation,  traceability,  verification, ... 
o  Activities  (function-based  behavior) 
o  Automated  model-based  document  generation 
o  Collaborative  modeling  environments 

o  Healthy,  viable,  growing  technology  ecosystem  (with  many  SysML  users, 
production  tools,  good  support,  extensive  learning  resources,  etc.) 

These  slides  are  excerpts  from  two  courses  in  our  short  course  series,  SysML  101  and  102,  which 
we  have  taught  since  Aug  2008  to  over  500  participants  from  government  and  industry  (see 
Slide  1-16). 

We  recommend  that  the  reader  go  through  the  slides  to  gain  an  introductory 
understanding  of  the  SysML  language  and  its  implementation  in  a  representative  tool 
(MagicDraw),  or  to  refresh  and  see  our  view  of  the  technology  (especially  SysML  parametrics)  if 
the  reader  already  has  some  familiarity  with  SysML.  Additional  learning  resources  including 
tutorials  are  available  at  the  official  OMG  SysML  website:  www.omgsvsml.org. 
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3  SysML-based  VV&A:  Concepts  and  Examples 


In  this  section  we  highlight  a  wide  variety  of  SysML-based  W&A  concepts.  Table  l  summarizes 
these  concepts  (from  CT-l  to  CT-16)  and  lists  one  or  more  examples  we  utilize  to  demonstrate 
each  concept.  CT-17  includes  several  additional  concepts  that  we  believe  could  be  demonstrated 
in  future  phases  based  on  results  to  date  with  CT-i  to  CT-16.  This  table  shows  a  simplified 
organization  scheme  that  starts  with  lower-level  basic  concepts  and  moves  up  to  progressively 
higher-level  concepts  (which  often  utilize  the  lower-level  concepts  as  building  blocks).  There 
are  probably  other  good  ways  to  break  down  these  concepts  further  and  to  categorize  them  at  a 
higher  fidelity  (e.g.,  by  sub-concept,  MIM  type  (CT-16),  model  type,  use  case  type,  scenario 
type,  solution  method  type,  and  so  on).  Determining  categorization  schemes  that  would  be  most 
useful  for  various  stakeholders  is  an  area  for  future  research. 

The  rest  of  this  section  describes  each  concept  briefly  and  refers  to  its  corresponding 
slides  in  presentation  Part  3  where  application.  At  the  beginning  of  each  subsection  we  note 
which  MIM  pattern(s)  that  concept  primarily  deals  with  (and  we  reference  this  further  where 
needed  in  the  text  using  a  notation  like  this:  [MIM  pattern  ao]. 
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Table  1  -  SysML-based  W&A  concepts  and  examples  demonstrated  in  RT21  Phase  1. 


id  VV&A  Concept  Example(s) 

Core  embedded  V&V  concepts 

CT-1 

Language-level  integrity:  automated  units  consistency 

MagicDraw  SysML  detecting  units  mismatch 

CT-2 

Language-level  integrity:  automated  equation  checking 

ParaMagic  detecting  wrong  parameter  name 

CT-3 

Language-level  integrity:  other  examples 

Model  integrity  (e.g.,  multiplicity  checking); 
propagating  name  updates;  instance  updates;  etc. 

CT-4 

Augmented  language-level  integrity:  ensuring  best  practices,  etc. 

Model  checking  suites  in  MagicDraw  and  ParaMagic 

CT-5 

Leveraging  built-in  checking  by  solvers  /  external  tools  as 
wrapped  in  a  SysML  context 

Mathematica  detecting  overconstrained  system  of 
equations,  etc. 

Higher-level  concepts  -  roundl 

CT-6 

V&V  building  blocks 

Margin  block  and  comparator  block 

CT-7 

Automated  requirements  verification 

FireSat,  SimpleSat,  etc.  (parametrics,  margin,  ...) 

CT-8 

Embedded  unit  tests 

LinkageSystems,  build  block  libraries,  ... 

CT-9 

Automated  roll-up  of  embedded  unit  tests  (basic  multi-level  test) 

LinkageSystems,  HomeHeatingSystem 

CT-10 

Automated  roll-up  of  embedded  multi-level  tests 

Combining  above,  ... 

CT-1 1 

“DNA  signatures”  -  user  interaction  with  model  for  intuitive  visual 
inspection  to  aid  model  comprehension,  V&V,  debugging,  etc. 

LinkageSystems,  FireSat/NGDMC,  etc.  (and  above) 

Higher-level  concepts  -  round2 

CT-1 2 

Verification  of  external  core  solvers  via  auto-generated  native  test  models 

12.1 

Core  math  solvers:  Mathematica,  OpenModelica,  Matlab  SMT 

Unit  test  cases  (to  verify  new  solver  releases,  etc.); 

XaiTools  production  test  suite  (-150  models) 

CT-1 3 

Automated  verification  of  external  simulation/analysis  models/tools  via  wrapping 

13.1 

System  dynamics:  Matlab/Simulink 

HomeHeatingSystem 

13.2 

Finite  element  analysis  (FEA):  Ansys 

LinkageSystems 

CT-1 4 

Automated  verification  of  external  design/descriptive  models/tools  via  wrapping 

14.1 

Spreadsheets:  Excel 

Excavator  manufacturing  cost  estimator 

14.2 

CAD:  NX  (MCAD);  Expedition,  etc.,  via  AP210  (ECAD) 

Vehicle,  MiniSatellite  electronics  (as  recorded  demos) 

14.3 

System  mission  design  (and  LVC  sims):  STK 

Satellite  orbit  &  ground  station  comm.  sys.  design 

CT-1 5 

Automated  verification  tests  on  physical  systems 

15.1 

Activity-based  test  scripts  with  mobile  robotics 

Rover  functionality  scenarios  (sensors,  camera,  ...) 

Higher-level  concepts  -  round3 

CT-1 6 

MIM:  an  architecture  for  M&S  patterns 

CT-1 7 

Other  concept  extensions  (which  can  be  demonstrated  using  similar  capabilities  as  above) 

17.1 

Auto-generating  documents  from  SysML  models  to  support  VV&A  (for  V&V  traceability  &  status,  accreditation  reports,  ...) 

17.2 

Managing  accreditation  workflows  and  artifacts 

17.3 

Aiding  M&S  validation  via  test  results  data  capture  and  comparator  usage 

17.4 

Capturing  SME  validation  criteria  for  future  automated  re-validation  usage 

17.5 

Managing  simulation  data  flow  and  data  pedigree  (e.g.,  for  sim  inputs/outputs) 

17.6 

Managing  models  &  simulations  themselves  as  systems  using  SysML  (with  requirements,  structure,  behavior,  etc.) 

Main  Test  Cases 

-  Mobile  robotics  (IPRE  Scribbler  h/w  with  Myro  software  platform) 

-  Excavator  test  bed  with  linkage  systems 

-  Satellite-to-ground  station  communication  link  simulation 

-  FireSat  /  NGDMC  satellite 

-  Short  course  tutorials  (vehicle  fuel  system,  space  satellite, ...) 

-  Home  heating  system 
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3.1  Core  embedded  V&V  concepts 

This  subsection  covers  some  of  the  most  basic  V&V  concepts  based  on  the  “better  ingredients, 
better  pizza”  philosophy  described  above.  I.e.,  we  show  here  how  SysML  is  effective  to  help  V&V 
the  most  basic  M&S  ingredients— a  situation  that  is  necessary  before  one  can  reasonably  claim 
that  higher-level  M&S  aspects  are  verified  and/or  validated. 

A  formalized  language  such  as  SysML  typically  includes  integrity  constraints  such  as 
rules  that  must  hold  for  a  model  to  be  internally  valid.  Some  constraints  may  be  considered 
more  at  the  syntactic  level,  which  is  analogous  to  a  traditional  computer  language  like  Java 
having  syntax  rules.  Other  constraints  are  more  at  the  semantic  level,  which  is  analogous  for 
example  to  not  wanting  infinite  loops  in  a  Java  program. 

This  subsection  gives  examples  of  integrity  constraints  at  the  SysML  language  level,  at 
the  SysML  tool  level,  and  at  the  core  external  tool  level  (e.g.,  in  core  external  solvers  that  SysML 
uses  for  its  parametric  equations). 


CT-1  Language-level  integrity:  automated  units  consistency 

Related  MIM  pattern(s):  cross-cutting  infrastructure 
Example:  MagicDraw  SysML  detecting  units  mismatch 

Slide  CT-l-l  illustrates  a  key  basic  constraint  that  says  units  consistency  needs  to  be  maintained 
throughout  a  model.  It  shows  two  versions  of  a  SysML  parametrics  diagram  for  part  of  a  vehicle 
model.  The  version  on  the  left  is  fine  in  that  all  variables  and  equations  have  consistent  units. 

The  version  on  the  right  is  a  different  story— here  the  modeler  has  accidently  connected  a 
fuel  amount  variable  (with  units  of  gallons)  to  a  mileage  variable  (with  units  of  miles)  as  seen 
with  connection  elO.  And  the  modeler  did  a  similar  mistake  with  connection  ell.  The  SysML 
tool  automatically  detects  both  issues  and  reports  the  specifics  in  the  window  at  the  bottom.  It 
is  not  shown  here,  but  the  tool  can  also  offer  suggested  ways  to  fix  the  problem  (which  may  or 
may  not  be  useful  depending  on  the  intent  of  the  modeler). 

This  type  of  integrity  checking  may  seem  simplistic,  but  the  value  and  impact  cannot  be 
overstated.  Unfortunately  significant  system  failures3  and  even  loss  of  life  have  been  caused  by 
inconsistent  units. 


CT-2  Language-level  integrity:  automated  equation  checking 

Related  MIM pattern(s):  cross-cutting  infrastructure 

In  Slide  CT-2-l  we  see  another  automated  verification  capability  that  ensures  basic  language- 
level  integrity.  The  slide  shows  the  top  fragment  of  the  same  SysML  parametric  diagram 


3  See  “metric  mix-up”  at  http://en.wikipedia.org/wiki/Mars  Climate  Orbiter,  worker  death  during  construction  of 
the  1996  Olympic  Aquatic  Center,  and  so  on. 
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employed  as  an  example  in  CT-i.  The  top  version  is  valid,  but  the  bottom  version  is  invalid.  In 
this  case  a  SysML  add-on  tool  for  parametrics  solving  called  ParaMagic®  catches  the  errors  as 
seen  at  the  bottom  of  the  slide:  the  parameter  names  (as  seen  by  the  names  near  the  small 
squares)  on  the  eqn2  constraint  property  do  not  match  the  names  given  in  the  constraint 
expression  equation.  I.e.,  the  tool  automatically  detects  that  myfuel  and  aal  are  not  consistent 
with  the  equation  definition  in  the  constraint  block.  Finding  such  errors  in  a  large  model  can  be 
rather  tedious,  whereas  they  are  automatically  detected  here  and  the  SysML  structure  aids 
pinpointing  them  for  fixing. 


CT-3  Language-level  integrity:  other  examples 

Related  MIM pattern(s):  cross-cutting  infrastructure 

This  section  gives  several  other  examples  showing  how  tools  ensure  language-level  integrity  in  a 
SysML  model.  The  benefit  is  your  resulting  model  has  a  much  greater  chance  of  being  problem- 
free  at  its  core  versus  other  manual  approaches  where  it  is  easy  for  inconsistencies  to  slip  in 
(e.g.,  PowerPoint-based  modeling).  A  related  benefit  is  avoiding  this  situation:  if  your  model  is 
not  valid  at  its  core,  then  most  anything  you  to  do  with  your  model  is  suspect  and  may  mislead 
decision  makers. 


CT-3.1  Model  integrity  checking:  instance  consistency  with  element  definitions 

Another  basic  language  integrity  feature  is  ensuring  that  an  instance  of  an  element  is  consistent 
with  the  structural  definition  of  that  element  (analogous  to  a  filled-out  registration  form  being 
consistent  with  the  original  definition  of  the  form,  such  as  allowing  only  one  person  to  register 
on  a  given  form). 

Slide  CT-3-1  illustrates  how  a  SysML  tool  automatically  checks  for  such  errors.  The  slide 
upper  portion  shows  a  model  fragment  defining  that  a  Vehicle  has  two  tanks  called  tankl  and  tank2. 
Per  the  SysML  spec  this  model  indicates  that  these  tankl  and  tank2  properties  can  be  filled  in  with 
only  one  tank  instance  each.  The  instance  version  in  the  lower-left  is  thus  valid  as  it  shows 
tankl=ft270  and  tank2=ft280.  The  instance  version  in  the  lower-right,  however,  is  not  valid  as  it 
shows  tankl=ft270,  ft280  (i.e.,  two  instances  being  used  for  tankl).  The  tool  warns  the  modeler  of 
this  error  by  flagging  it  red  and  giving  the  message  “Too  many  slot  values”  (where  “slot”  is  a 
SysML  term  analogous  to  a  specific  blank  on  a  specific  form).  This  error  is  similar  to  trying  to 
enter  in  two  names  on  a  conference  registration  form  instead  of  using  one  form  for  each  person. 
The  tool  automatically  detects  such  issues  and  advises  the  modeler  with  possible  options  to  fix 
them. 


CT-3.2  Propagating  model  updates 

Slide  CT-3-2  illustrates  another  basic  language  integrity  feature  that  good  SysML  tools  support: 
keeping  all  model  elements  and  diagrams  consistent  with  the  underlying  model  structure  even 
as  the  modeler  changes  the  model. 
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On  the  left  is  the  original  model  that  includes  a  Vehicle  property  named  range.  The  modeler 
later  changes  this  property  name  to  distance_range  (as  seen  in  the  middle  of  this  slide).  The  tool 
immediately  and  automatically  updates  all  related  model  elements  and  all  diagrams  that  depict 
that  property,  as  seen  in  two  diagram  examples  in  the  right.  Good  tools  will  also  do  the  same 
type  of  updates  if  the  modeler  performs  more  significant  structural  changes  such  as  adding  a 
new  property,  deleting  an  existing  property,  and  so  on. 

This  capability  may  seem  trivial  and  what  you  would  naturally  expect  from  a  tool.  And 
you  would  be  correct  to  expect  that,  but  the  most  popular  systems  engineering  tools 
(PowerPoint  and  Visio)  do  not  even  come  close,  and  other  tools  often  fall  short  (thus  requiring 
manual  update  effort  that  is  tedious,  costly,  and  error-prone).  In  good  SysML  tools,  however, 
automatically  maintaining  consistency  and  propagating  model  updates  like  this  has  become  a 
commodity  feature. 


CT-4  Augmented  language- level  integrity:  ensuring  best  practices,  etc. 

Related  MIM  pattern(s):  cross-cutting  infrastructure 

While  the  SysML  language  spec  has  numerous  integrity  rules  like  those  illustrated  above,  it  does 
not  necessarily  cover  everything  a  given  organization  may  want  to  see.  Here  are  two 
representative  situations  (where  additional  automated  checking  is  needed  to  detect  such 
problems):  (a)  a  modeling  practice  is  not  supported  by  the  tools  a  particular  organization  uses 
(even  though  that  practice  is  allowed  by  the  SysML  spec),  and  (b)  an  organization  has  their  own 
styles  and/or  domain-specific  rules  that  they  want  all  their  models  to  conform  to. 

Here  is  an  example  of  situation  (a):  SysML  technically  allows  block  names  and  property 
names  to  have  spaces  and  other  non-alphanumeric  characters.  But  many  simulation  tools  and 
math  tools  do  not  like  variable  names  to  have  such  characters.  Thus,  to  ensure  better 
robustness,  reusability,  and  compatibility  with  external  tools,  some  SysML  tools  provide  checks 
for  best  practices  like  this.  Slide  CT-4-1  demonstrates  this  starting  with  the  same  valid  SysML 
model  fragment  described  in  CT-2.  The  bottom  of  the  slide  shows  how  tools  like  ParaMagic 
automatically  detect  non-recommended  characters  and  warns  the  modeler.  Otherwise, 
additional  errors  may  occur  in  math  solvers  and  other  downstream  simulation  tools  that  use  this 
SysML  model,  and  these  errors  typically  have  more  serious  effects  and/or  are  more  difficult  to 
detect.  The  SysML  spec  supports  extensibility  and  thus  readily  enables  organizations  to  add 
tightened  restrictions  like  this. 


CT-5  Leveraging  built-in  checking  by  external  solvers  /  tools  as  wrapped  in 
a  SysML  context 

Related  MIM pattern(s):  eo 

In  spite  of  capabilities  like  that  described  in  CT-4,  there  may  still  be  problematic  situations  that 
a  SysML  tool  itself  does  not  detect,  but  which  it  can  facilitate  detecting.  One  example  is  a  SysML 
model  that  has  an  overconstrained  system  of  equations.  Math  solvers  such  as  Mathematica, 
Matlab  SMT,  and  OpenModelica  readily  catch  such  issues.  When  a  SysML  plugin  like 
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ParaMagic  employs  these  math  tools  in  an  automated  manner,  it  can  ask  the  math  tool  to  tell  it 
if  anything  went  wrong  during  the  solution  process.  Thus  the  SysML-based  approach  leverages 
these  external  capabilities  in  a  structured  context,  and  it  does  not  need  to  re-invent  the  wealth  of 
knowledge  and  V&V  that  such  solvers  already  have. 


3.2  Higher-level  concepts  -round! 


CT-6  Verification  &  validation  building  blocks 

Related  MIM  pattern(s):  eo 

This  section  shows  how  you  can  create  V&V  building  blocks  that  are  quite  useful  and  applicable 
in  numerous  contexts.  These  blocks  capture  several  basic  V&V  concepts  in  a  modular  reusable 
form.  They  are  fundamental  elements  for  V&V  just  as  basic  electrical  elements  (such  as 
resistors,  capacitors,  transistors,  and  diodes)  are  fundamental  to  electrical  circuits.  We 
highlight  two  such  blocks  here:  a  margin  block  and  a  comparator  block.  We  also  briefly  note 
other  similar  blocks  and  variations  that  could  be  similarly  created  to  provide  practitioners  a 
more  complete  set  of  V&V  building  blocks. 


CT-6.1  Margin  block 

Slide  CT-6-i  shows  the  SysML  definition  structure  for  a  margin  block.  The  SysML  parametrics 
diagram  (par)  on  the  left  gives  the  primary  margin  equation  (rl)  and  also  a  verdict  test  equation 
(r2).  As  explained  in  the  note  on  this  diagram,  margin  quantifies  the  comparison  between  an 
maximum  allowable  value  versus  some  determined  value.  One  common  application  of  this  concept 
is  the  case  where  the  maximum  allowable  value  is  dictated  by  a  requirement  (e.g.,  maximum 
allowable  mass)  and  the  determined  value  is  calculated  based  an  analysis  model  or  simulation 
model  for  the  current  design.  In  other  cases  the  determined  value  is  found  by  some  other  means 
such  as  a  physical  measurement  as  part  of  a  test  on  the  current  system. 

The  margin  concept  is  commonly  employed  in  the  aerospace  industry  to  help  quantify 
design  status  with  respect  to  requirements  and  objectives  (e.g.,  in  stress  analysis  to  see  how 
much  margin  a  wing  structure  has  before  exceeding  its  material  yield  stress).  We  illustrate  this 
type  of  application  in  the  CT-7.1  section  below  to  automatically  verify  if  a  satellite  system  design 
meets  several  requirements  dealing  with  mass  and  power  limits. 

Other  engineering  disciplines  similarly  utilize  margin  and/or  related  concepts  such  as 
factor  of  safety.  Note  that  these  concepts  are  also  useful  for  non-physical  systems,  for  example, 
to  compare  the  actual  determined  cash-on-hand  that  a  business  has  versus  its  desired  level  of 
cash-on-hand  that  gives  a  buffer  for  cash  flow  purposes. 

The  margin  block  implementation  shown  here  handles  perhaps  the  most  common  needs, 
but  there  are  other  useful  variations  it  does  not  support  including  minimum  allowables,  ranges, 
tolerances,  multiple  levels  of  acceptability  (not  just  pass/fail),  expected  delta  trend  versus 
baseline,  and  so  on.  Thus,  one  recommendation  is  that  the  sponsor  consider  supporting  the 
development  of  V&V  building  block  libraries  that  would  include  a  whole  suite  of  such  blocks  (as 
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well  as  similar  variations  for  the  comparator  concept  described  next).  Making  such  libraries 
readily  available  to  the  DoD  supply  chain  is  one  way  to  foster  widespread  practice  of  this 
approach  and  to  achieve  the  related  benefits:  Build  a  useful  library  and  they  will  come! 


CT-6.2  Comparator  block 

The  comparator  block  illustrated  in  Slide  CT-6-2  has  similar  concepts  and  intent  as  the  above 
margin  block.  The  main  difference  is  comparators  are  mostly  used  to  check  for  equality, 
whereas  margin  blocks  expect  to  have  a  non-zero  delta  between  determined  and  allowable.  A 
comparator  automatically  verifies  if  an  actual  value  is  equal  to  an  expected  value.  Thus 
comparators  can  be  employed  for  M&S  V&V  purposes  practically  everywhere,  for  example,  to 
verify  that  a  simulation  produces  expected  values  under  specified  circumstances. 

We  demonstrate  this  usage  below  in  several  examples  (CT-8.1,  CT-9.1,  CT-13.1,  etc.)  to 
verify  design/analysis/simulation  models  ranging  from  mechanical  parts  to  heating  systems  to 
space  systems.  At  Georgia  Tech  we  use  this  approach  in  conjunction  with  InterCAX  LLC  to 
automatically  verify  software  libraries  and  SysML  models  that  are  utilized  in  the  industrial- 
grade  products  that  InterCAX  sells  commercially  (with  customers  including  NASA  JPL,  Sandia, 
and  many  1st  and  2nd  tier  companies  in  the  DoD  supply  chain). 


CT-7  Automated  requirements  verification 

Related  MIM pattern(s):  bo,  co,  do 

This  section  shows  how  SysML  enables  automatically  verifying  requirements.  This  approach 
can  be  applied  to  requirements  for  physical  systems  as  well  as  to  requirements  for  M&S. 


CT-7.1  Using  margin  blocks — SimpleSat  example 

These  slides  show  the  SysML-based  design  of  a  basic  satellite,  which  we  use  for  teaching  SysML 
concepts.  It  employs  the  margin  block  introduced  above  (CT-6.1)  to  verify  three  requirements 
(as  seen  by  the  three  black  diamond  part  property  relations  connected  to  Margin  Block  in  Slide 
CT-7-1).  Slide  CT-7-4  shows  a  solved  and  verified  design  state  as  displayed  in  the  ParaMagic 
browser.  The  resulting  margin  value  (denoted  mos  in  this  model  version)  in  each  margin  block 
indicates  that  this  design  meets  the  mass  requirement  (by  1%  as  seen  in  reqVerifierMass)  and  the 
power  subsystem  power  requirement  (by  11%  as  seen  in  reqVerifierPower),  but  fails  the  controller 
subsystem  rating  requirement  (by  a  negative  9%  as  seen  in  reqVerifierRating). 


CT-7.2  Using  direct  pass/fail  expressions — FireSat/NGDMC  example 

This  example  (Slide  CT-7-5)  is  based  on  a  SysML  implementation  of  the  FireSat  satellite  design 
described  in  the  widely-used  Space  Mission  Analysis  and  Design  (SMAD)  handbook  by  Wertz 
and  Larson  plus  extensions  for  NGDMC.  Slide  CT-7-6  shows  a  solved  and  verified  design  state 
as  displayed  in  the  ParaMagic  browser.  In  this  model  the  system  engineer  uses  direct 
conditional  expressions  (instead  of  margin  blocks)  to  automatically  verify  the  status  of  two 
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requirements:  one  for  cost  (cosRtl)  and  another  for  satellite  scan  area  coverage  (covRtl).  A  value 
of  one  (l)  for  each  corresponding  verdict  attribute  (CostReqtVerify  and  CoverReqtVerify)  indicates  the 
system  design  passes  these  requirements  (versus  a  zero  (o)  would  indicate  it  fails). 

This  direct  conditional  expression  approach  is  also  effective  modeling  style,  though  in 
general  an  explicit  margin  block  approach  is  more  recommended  because  it  has  better 
modularity  and  reusability. 


CT-8  Embedded  unit  tests 

Related  MIM  pattern(s):  do 

This  concept  applies  software  unit  test  thinking  (as  see  in  technologies  like  JUnit  for  Java)  to  the 
design  of  generalized  systems,  where  a  system  can  be  an  M&S  system  (or  practically  any  type  of 
system  model)  and  its  building  blocks.  The  main  idea  explored  here  is  adding  automated  unit 
testing  at  every  system  level— from  the  lowest-level  building  block  to  the  highest-level  system-of- 
systems— thus  better  ensuring  verification  at  each  level  (as  well  as  some  types  of  validation  as 
discussed  in  CT-17). 

CT-8.1a  Using  comparator  blocks — linkage  system  example 

Slide  CT-8-1  illustrates  the  basic  SysML-based  unit  test  pattern,  which  has  the  element-under¬ 
test  (EUT)  (a.k.a.,  the  system  being  verified)  and  (UT)  the  unit  test  itself,  which  uses  the 
comparator  block  structure  described  in  Section  CT-6.2  one  or  more  times  like  virtual  test 
probes  (TPj).  In  this  case  there  are  seven  comparator  block  usages  (as  denoted  by  cmpOl  to 
cmp07),  each  of  which  compares  an  expected  value  (from  a  golden  instance)  with  the  current 
actual  value  of  a  key  system  property. 

You  could  conceivably  apply  an  exhaustive  form  of  this  pattern  and  use  a  comparator 
block  for  each  and  every  property  in  the  EUT.  The  exhaustive  comparison  approach  is 
recommended  at  the  lower  building  block  levels,  but  that  could  get  tedious,  redundant,  and/or 
not  impractical  for  large  systems.  So  the  approach  used  in  this  example  is  like  attaching  test 
probes  to  seven  key  properties  in  the  system.  Since  many  of  the  properties  are  interdependent 
in  some  way  (seen  DNA  signature  in  Slide  CT-8-3),  you  are  likely  to  catch  any  issues  in  the 
system  by  checking  the  values  of  these  seven  test  probes.  Future  project  phases  could 
investigate  ways  to  auto-generate  the  right  test  probes  for  a  desired  level  of  risk  (e.g.,  based  on 
sensitivity  analysis  or  related  testing  algorithms  from  the  electronics  and  software  domains). 

CT-8.1b  Using  comparator  blocks — home  heating  system  simulation  example  (Simulink) 

See  also  Slide  CT-13-3  (and  related  slides)  to  see  how  we  applied  this  same  unit  test  pattern  to  a 
home  heating  system  simulation  based  on  a  Simulink  model. 

CT-8.2  Using  comparator  blocks — building  block  examples 

There  are  no  slides  for  these  examples,  but  you  can  probably  readily  visualize  how  the  same  unit 
test  concept  applied  to  the  above  linkage  system  could  be  applied  to  practically  any  model  level. 
Thus,  you  can  apply  unit  testing  to  the  libraries  that  contain  the  lowest-level  building  blocks, 
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including  the  sleeve  block  used  in  the  linkage  system,  as  well  as  the  circle  block  used  in  the 
sleeve  block,  and  so  on  down  to  the  most  primitive  building  block.  A  key  point  is  that  you  can  do 
this  testing  at  the  library  level  independent  of  any  particular  system  built  from  that  library.  E.g., 
the  golden  instances  you  use  to  test  building  blocks  like  sleeve  and  circle  would  normally  not  be 
the  sleeve  and  circle  instances  that  any  particular  linkage  system  instance  utilizes. 

We  recommend  to  embed  unit  tests  like  this  starting  with  the  most  primitive  building 
blocks  and  working  up  from  there.  This  way  you  can  verify  all  your  internally-  and  externally- 
supplied  libraries  (applying  CT-9)  before  using  them  in  your  system  modeling  (and  you  can 
automatically  re-verify  them  whenever  something  changes,  such  as  when  new  editions  of  your 
3rd  party  libraries  become  available). 


CT-9  Automated  roll-up  of  embedded  unit  tests  (basic  multi -level  test) 

Related  MIM pattern(s):  do 

This  concept  connects  together  two  or  more  unit  tests  like  those  described  in  the  previous 
section  (CT-8).  Slide  CT-9-1  shows  this  pattern  (similar  to  the  above  unit  test  (UT)  pattern) 
applied  again  to  linkage  systems,  but  now  a  multi-unit  test  (MUT)  block  takes  advantage  of  the 
unit  test  blocks  already  defined.  In  this  linkage  system  case,  this  multi-unit  test  is  verifying  two 
linkage  system  instances  and  rolling  up  the  combined  result.  The  MUT  verdict  is  thus  pass  only 
if  both  unit  tests  are  pass. 

In  this  way  you  can  define  a  suite  of  unit  tests  for  better  test  coverage  (e.g.,  a  UT  for  one 
instance  that  has  values  at  one  extreme,  another  UT  for  an  instance  with  values  at  the  other 
extreme,  and  several  UTs  for  other  instances  with  special  case  values,  etc.).  We  have  similarly 
demonstrated  this  pattern  with  the  home  heating  system  (not  shown  here)  applying  the  UT  seen 
in  CT-8. lb. 


CT- 10  Automated  roll-up  of  embedded  multi-level  tests 

Related  MIM  pattern(s):  do 

By  extending  the  multi-unit  test  concept  a  bit  further,  you  can  probably  easily  imagine  rolling  up 
automated  testing  like  this  to  practically  any  level  such  that  tests  in  a  parent  system  would 
automatically  run  all  tests  in  all  its  child  subsystems  and  so  on  down  the  line.  One  strategy  is  to 
have  (a)  a  “subset  roll-up  test  network”  of  embedded  tests  like  this  as  a  quick  check  (where  this 
roll-up  test  network  includes  just  one  or  two  tests  at  each  level),  and  (b)  an  “exhaustive  roll-up 
test  network”  that  runs  all  tests  at  all  levels.  Another  strategy  is  to  leverage  the  same  kind  of 
thinking  that  is  found  in  continuous  integration  systems  for  software  development  (where 
automated  tests  like  these  are  continuously  run  whenever  triggered  by  a  system  change). 


CT-11  “DNA  SIGNATURES”  -  USER  INTERACTION  WITH  MODELS  FOR  INTUITIVE  VISUAL 
INSPECTION  TO  AID  MODEL  COMPREHENSION,  V&V,  DEBUGGING,  ETC. 

Related  MIM pattern(s):  cross-cutting  infrastructure 
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First  we  provide  a  brief  introduction  to  the  DNA  signature4  concept  referenced  in  Section  2  in 
relation  to  SysML  parametrics.  We  assume  the  reader  has  already  become  familiar  with  the 
basics  of  SysML  parametrics  by  reviewing  Part  2  slides  and  the  V&V  concepts  thus  far  (or  via 
equivalent  background  material).  Slide  2-19  (in  the  Part  2  presentation)  shows  the  primary 
DNA  signature  nomenclature  and  how  it  maps  to  SysML  parametrics  nomenclature.  Briefly,  a 
yellow  symbol  in  a  DNA  signature  represents  a  SysML  value  property,  a  blue  symbol  represents 
a  SysML  constraint  parameter,  and  a  red  symbol  represents  a  SysML  constraint  property.  An 
informal  description  for  each  of  these  is  shown  in  parenthesis:  a  system  attribute,  a  local 
variable,  and  an  equation  usage.  The  fuel  tank  example  shown  in  Slide  2-19  has  only  three  value 
properties  and  one  constraint  property,  and  thus  its  DNA  signature  closely  matches  its  SysML 
parametric  diagram. 

The  building  block  nature  of  SysML  and  the  usefulness  of  the  DNA  signature  view 
becomes  more  evident  in  the  vehicle  example  in  Slide  2-25.  The  Vehicle  block  uses  the  Fuel_Tank 
block  twice  as  two  part  properties  named  tankl  and  tank2.  And  the  Vehicle  block  has  five  constraint 
properties  (representing  five  equation  usages)  that  together  determine  several  vehicle-level  fuel 
and  range  attributes.  Note  however,  that  the  vehicle  DNA  signature  (Slide  2-26)  has  seven  red 
symbols  (indicating  seven  constraint  properties)  instead  of  five— why  is  this?  It  comes  from  the 
vehicle  having  two  fuel  tanks: 

(5  eqns.  in  Vehicle  block)  +  (1  eqn.  in  Fuel_Tank  block)  x  2  part  properties  =  7  eqns.  total 

Keep  in  mind  that  this  “block  built  from  blocks”  pattern  can  be  nested  arbitrarily  deep  (while  in 
this  case  there  is  only  one  level  of  nesting).  In  a  nutshell  that  is  how  you  can  get  complex  DNA 
signatures  fairly  quickly  even  though  the  SysML  parametric  diagram  for  any  given  block  may 
not  look  veiy  complex  (see  examples  in  the  slides  starting  with  Slide  2-28  in  Part  2).  In  fact  it  is 
good  practice  for  any  given  block  to  define  no  more  than  5-10  equations  at  its  own  level— beyond 
that  it  should  start  using  build  blocks  to  capture  additional  equations  and  so  on. 

Model  builders  find  that  SysML  blocks  and  their  parametrics  aspects  are  helpful  for 
constructing  a  model,  and  that  DNA  signatures  (which  are  auto -generated  from  their  resulting 
model)  are  helpful  for  debugging  and  understanding  the  total  effect  of  the  emergent  model. 
Thus,  using  these  various  views  together  facilitates  both  composing  and  comprehending 
complex  models.  Next  we  describe  how  DNA  signatures  aid  doing  V&V  for  M&S  in  particular. 

CM  1.1  Verification  of  building  blocks  and  higher-level  models 

When  you  create  modular  building  blocks  using  a  technology  like  SysML,  it  helps  to  have  a  quick 
visual  means  to  verify  them.  The  most  primitive  (leaf-level)  building  blocks  tend  to  have  ten 
(10)  or  less  equations,  and  thus  their  DNA  signatures  are  relatively  simple  and  quickly 
recognizable.  Creators  of  building  block  libraries  (and  also  users  of  those  libraries)  come  to 
learn  their  building  block  DNA  signatures  and  immediately  recognize  at  a  visual  glance  when 
something  has  changed.  Hence,  DNA  signatures  provide  an  intuitive  visual  means  for 


4  DNA  signatures  are  not  officially  part  of  SysML  l.x  (though  it  technically  could  support  a  similar  view,  but  in 
practice  no  tools  support  that  yet).  We  developed  this  view  in  our  research  based  on  our  experiences  with  SysML 
parametrics  (and  its  foundational  composable  object  concepts)  to  provide  benefits  like  those  noted  in  this  section.  If 
more  and  more  people  become  familiar  with  DNA  signatures  and  find  them  useful  like  we  do,  perhaps  they  will 
become  an  official  part  of  a  future  SysML  spec  release. 
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verification  by  humans.  They  give  new  capabilities  and  depth  to  enable  the  saying  “something 
does  not  look  right”. 

The  same  can  be  said  for  higher  level  complex  models  built  from  these  primitives.  If 
model  creators  and  users  spend  some  time  with  a  specific  complex  model,  they  get  to  know  what 
it  looks  like  (and  what  its  subsystems  and  primitives  look  like)  via  its  DNA  signature.  At  higher 
levels  it  can  be  admittedly  difficult  to  detect  subtle  changes,  but  they  can  readily  see  changes 
that  have  greater  impact  (and  they  can  always  isolate  and  view  any  single  subsystem  or  building 
block  to  verify  it  by  itself). 

CT-11.2  Validation  via  expected/unexpected  structure 

One  way  DNA  signatures  help  subject  matter  experts  (SMEs)  validate  a  model  is  by  enabling 
them  to  see  expected  and/or  unexpected  structure  (Slide  CT-ll-l).  For  example,  when  someone 
was  recently  building  a  SysML  model  for  sizing  satellite  systems,  the  DNA  signature  showed  two 
distinct  (disconnected)  subgraphs:  one  showing  the  equation  relations  among  mass-type 
properties  and  another  showing  the  same  for  power-type  properties.  A  satellite  SME  could  see 
right  away  (without  inspecting  any  further  details  whatsoever)  that  the  model  was  not  a  good 
model  of  satellite  system  reality— the  DNA  signature  clearly  indicated  that  the  model  did  not 
consider  mass  and  power  to  have  any  effect  on  each  other  (whereas  in  reality  the  power  system 
solar  panels  and  batteries  do  indeed  have  mass).  An  SME  would  expect  the  model  to  relate 
power  and  mass  somehow,  which  would  readily  show  up  in  the  DNA  signature  as  one  or  more 
visual  connections  in  the  equation  graph.  The  DNA  signatures  in  CT-9.1  and  CT-8.ia  provide 
additional  examples,  as  they  have  several  disconnected  subgraphs  and  even  some  dangling  value 
properties  (not  connected  to  anything)— these  situations  may  raise  flags  that  warrant  further 
investigation  (depending  on  the  intent  of  the  model  and  its  domain  semantics). 

Similarly  there  can  be  cases  where  the  DNA  signature  contains  unexpected  connections 
that  would  cause  an  SME  to  investigate  further  and  perhaps  detect  an  invalid  aspect  of  the 
model.  Continuing  the  satellite  example,  if  the  SME  sees  a  direct  connection  between  battery 
mass  and  solar  panel  power  generation,  there  is  probably  something  wrong  (since  the  former 
has  more  to  do  with  energy  storage  and  not  energy  generation,  and  thus  there  should  be  one  or 
more  mediating  relations  in  between).  In  summary  DNA  signatures  give  SMEs  a  transparent 
way  to  inspect  and  trace  a  model  from  its  highest  level  structure  to  its  lowest  level  building  block 
(and  to  all  points  in  between). 

CT-11.3  Validation  via  common  generic  patterns 

Another  way  DNA  signatures  help  SMEs  validate  a  model  is  by  enabling  them  to  look  for 
expected  patterns.  This  is  similar  to  CT-11.2  except  now  they  are  looking  for  one  or  more  overall 
“gestalt”  patterns  that  are  common  to  many  types  of  model  (versus  the  more  model-specific 
connections  in  CT-11.2). 

For  example  the  “pinwheel”  is  a  common  pattern  you  can  expect  to  see  whenever  you 
have  a  roll-up  type  of  calculation  at  any  given  system  level.  Slide  CT-ll-l  shows  this  pattern  for  a 
recycling  facility,  where  each  “arm”  of  the  pinwheel  is  one  recycling  process  that  an  electronics 
device  goes  through  to  get  disassembled  and  recycled.  The  center  of  the  pinwheel  is  the  energy 
roll-up  equation  (which  indicates  how  much  total  energy  the  facility  uses  across  all  its 
processes). 
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Thus,  SMEs  can  look  for  this  pinwheel  roll-up  pattern  in  a  model  in  their  domain  as  a 
quick  way  to  check  if  the  model  has  needed  capabilities  with  respect  to  whatever  roll-ups  are 
important  for  that  domain  (e.g.,  rolling  up  things  like  cost,  mass,  time,  capacity,  and  so  on).  As 
people  become  more  and  more  familiar  with  DNA  signatures  and  similar  concepts,  other  similar 
gestalt  patterns  are  likely  to  surface  and  find  similar  utility  for  V&V  purposes. 


3.3  Higher-level  concepts -round2 

Next  we  look  at  several  more  higher-level  concepts  that  build  upon  what  we  have  seen  so  far. 


CT-12  Verification  of  external  core  solvers  via  auto-generated  native  test 
MODELS 

Related  MIM pattern(s):  eo 

CT-12. 1  Core  math  solvers:  Mathematica,  OpenModelica,  MathWorks  Matlab  SMT 

As  seen  in  Section  2,  SysML  models  can  use  tools  like  ParaMagic  drive  the  auto-generation  of 
complete  analysis  and  simulation  models.  In  this  concept  section  we  highlight  how  to  leverage 
that  capability  to  automatically  verify  the  solvers  themselves  (and  related  variations  upon  that 
theme). 

Use  Case  l:  Verifying  different  solvers.  This  case  assumes  that  you  use  one  or  more  solvers  Si, 
S2,  ...,  Sn  as  part  of  your  M&S  environment  (e.g.,  where  Si=  Wolfram  Mathematica, 
S2=OpenModelica,  and  S3=MathWorks  Matlab  Symbolic  Math  Toolbox  (SMT)  in  our  testbed 
environment).  You  can  define  an  equation-based  model,  EMi,  as  a  SysML  model  that  should  be 
solvable  by  Si..Sn.  You  can  also  determine  known-good  output  results  for  EMi  for  a  specific  set 
of  inputs  (e.g.,  by  doing  manual  calculations,  by  finding  known -good  results  from  other 
independent  sources,  or  by  some  other  means). 

You  can  then  use  an  orchestration  tool  like  InterCAX  ParaMagic  to  solve  EMi  using 
solver  Si  and  confirm  that  Si  produces  the  expected  results.  You  can  also  use  the  exact  same 
SysML  model  EMi  to  do  the  same  verification  for  solvers  S2,  S3,  ...,  Sn.  By  doing  this  for 
enough  models  EMi..EMp  that  cover  your  M&S  class(es)  of  problems,  you  have  effectively 
verified  your  solvers  to  handle  those  class(es)  of  problems.  The  value  of  doing  this  with  a 
SysML-based  approach  becomes  more  evident  as  you  add  more  solvers  Sj  and  more  SysML- 
based  models  EMi. 

Slides  CT-12-1  onward  illustrate  this  approach  for  a  classical  basic  test  model  (an 
analytical  spring  system)  [Peak  et  al.  2007]  and  the  corresponding  auto-generated  input  job  files 
(and  output  file  results)  for  the  solvers  Si,  S2,  and  S3  listed  above.  We  use  this  iterative 
approach  at  Georgia  Tech  in  collaboration  with  InterCAX  to  verify  these  solvers  using  ~150 
different  models  (EM1..EM150).  These  models  cover  numerous  SysML  modeling  features, 
mathematical  situations,  and  complexity  ranges  (from  quick  tests  that  run  in  seconds  to 
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scalability  tests  that  run  in  loo’s  of  minutes;  from  models  built  internally  purely  for  test 
purposes  to  production  models  built  by  external  organizations). 

Use  Case  2:  Verifying  deviations  from  a  baseline  (deviations  in  solvers,  SysML  authoring 
tools,  models,  orchestration  tools,  etc.).  Once  you  have  a  baseline  configuration  established  and 
verified  per  Use  Case  1,  you  can  then  use  it  to  verify  several  types  of  variations.  For  example, 
when  a  vendor  releases  a  new  solver  version,  you  want  to  make  sure  it  still  works  fine  for  your 
types  of  problems.  Rather  than  expending  costly  error-prone  manual  effort,  you  can  auto-re-run 
your  SysML  model  suite  to  ensure  you  get  the  same  expected  results.  Of  the  ~150  test  cases 
above,  it  is  not  uncommon  to  find  l  or  2  test  cases  that  have  issues  with  the  new  solver  version 
(which  then  typically  results  in  bug  reports  and  the  vendor  needing  to  release  a  patch  to  fix  their 
solver,  or  sometimes  an  update  to  our  tools  due  to  changes  in  vendor  formats). 

Similarly,  whenever  we  update  our  models  SysML-based  EMj  themselves,  we  re-run  the 
affected  suite  portions  to  make  sure  these  models  themselves  still  work  as  expected.  And  we  do 
the  same  for  new  versions  of  our  XaiTools  FrameWork  (which  is  the  basis  for  the  commercial 
InterCAX  orchestration  tools  including  ParaMagic,  ParaSolver,  Melody,  and  Solvea)  as  well  as 
the  orchestration  tools  themselves. 


CT- 13  Automated  verification  of  external  simulation/analysis  models/tools 

VIA  WRAPPING 

Related  MIM  pattern(s):  eo 

This  concept  is  similar  CT-12  except  that  in  this  case  the  external  simulation/ analysis  model  is  a 
pre-existing  model  that  SysML  is  wrapping  in  a  black  box  manner.  I.e.,  in  CT-12  the  solver 
models  were  fully  and  automatically  generated  from  a  SysML  model,  but  in  this  CT-13  case,  the 
we  simply  wrap  an  existing  external  model  EMj— providing  it  inputs  and  then  checking  that  the 
outputs  match  expected  values  (without  the  SysML  model  needing  to  know  much  if  anything 
about  the  internals  for  EMj).  Note  that  some  wrappings  can  be  a  bit  more  gray  than  black  if 
some  degree  of  model  structure  is  replicated  (or  mapped  to)  in  the  SysML  model. 

This  concept  supports  several  helpful  use  cases  to  V&V  that  an  external 
simulation/ analysis  model  meets  expectations,  including  (a)  comparing  the  model  against 
known-good  results  as  determined  from  some  other  source,  and  (b)  comparing  the  model 
against  previous  versions  of  the  same  model  and/or  tool  (e.g.,  ensuring  that  the  model  results 
for  Matlab  2010a  are  consistent  with  what  you  had  before  in  Matlab  2008b).  Applications  with 
a  few  representative  simulation  and  analysis  tools  are  described  next. 


CT-13. 1  System  dynamics:  MathWorks  Matlab/Simulink 

Example:  HomeHeatingSystem.  These  slides  highlight  how  CT-13  works  with  a  Simulink  model 
(a  time-based  thermal  system  dynamics  model  in  this  case,  which  also  includes  operating  costs). 
Note  we  apply  here  a  similar  comparator  block-based  unit  test  pattern  as  seen  in  CT-8. 
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CT-13.2  Finite  element  analysis  (FEA):  Ansys 

Example:  LinkageSystems.  Slide  CT-13-5  highlights  how  CT-13  concepts  similarly  work  well  for 
an  Ansys  model  (a  2D  stress  and  deformation  analysis  model  in  this  case).  The  native  Ansys 
model  is  based  on  a  parameterized  script,  and  the  SysML  wrapper  provides  input/output  access 
to  a  selected  subset  of  those  parameters.  The  FEA  model  creator  may  have  many  parameters 
designed  into  the  FEA  model,  but  only  a  dozen  or  so  of  those  in  this  case  are  of  interest  in 
systems  engineering  and  V&V  contexts.  Note  the  usage  here,  too,  of  the  CT-7  pattern  (using 
margin  blocks),  and  also  how  we  could  apply  CT-8  to  wrap  this  in  a  unit  test  to  verify  Ansys 
itself. 


CT-14  Automated  verification  of  external  design/descriptive  models/tools 

VIA  WRAPPING 

Related  MIM  pattern(s):  ao 

This  concept  is  quite  similar  CT-13  except  that  in  this  case  the  external  models/tools  are 
intended  primarily  for  design  purposes  [MIM  pattern  ao]  (whereas  in  CT-13  the  external 
models/tools  are  primarily  for  analysis  or  simulation  purposes  [MIM  pattern  eo]).  Some  cases 
could  be  argued  to  be  a  combination  of  both  design  and  analysis/simulation  (as  some  tools  mix 
the  two  functionalities).  Like  CT-13,  these  employ  SysML-based  wrappings  around  existing 
models  in  a  black/gray  box  manner  (where  the  wrappings  connect  only  to  key  inputs  and 
outputs,  thus  leaving  most  of  the  external  model  details  to  be  handled  by  the  native  tool). 
Applications  with  a  several  representative  tool  varieties  are  given  here. 


CT-14.1  Spreadsheets:  Microsoft  Excel 

Example:  Excavator  manufacturing  ROM  cost  model  [Peak  et  al.  2009].  Similar  to  the  CT-13 
examples,  this  example  (Slide  CT-14-1)  illustrates  wrapping  a  spreadsheet  as  a  type  of  external 
model  where  the  SysML  context  provides  inputs  and  reads  outputs.  Thus,  we  can  apply  the 
same  unit  and  multi-level  comparator  block  test  probe  patterns  seen  in  CT-8/9/10  for  V&V 
purposes. 


CT-14.2  CAD:  Siemens  NX  (MCAD);  Mentor  Graphics  Expedition,  etc.,  via  AP210  (ECAD) 

Example:  vehicle  geometry;  MiniSatellite  system  &  electronics  (also  available  as  recorded 
demos).  These  examples  (starting  with  Slide  CT-14-2)  illustrate  similar  capabilities  as  the  other 
CT-14  examples,  except  they  use  a  somewhat  different  wrapper/interface  approach  (thus 
illustrating  that  SysML  supports  a  variety  of  approaches). 

The  other  examples  have  input/output  interfaces  that  are  configurable  at  the  native 
model  scripting  level  (or  even  the  coded  plugin  level  in  the  case  of  the  current  CT-14C 
prototype).  Thus,  they  take  a  bit  of  work  outside  the  SysML  model  for  their  initial  setup,  and 
then  after  that  they  are  highly  automated. 

These  examples  leverage  an  approach  that  is  a  bit  more  flexible.  The  interface  plugin 
establishes  the  SysML  wrapper  input/output  structure  automatically  based  on  the  native  model 
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and  then  keeps  automatically  synchronizes  them  in  an  on-demand  manner.  From  that  point 
onward  he  effect  and  usage  for  V&V  purposes  is  essentially  the  same  as  the  other  examples.  The 
MiniSatellite  example  combines  both  MCAD  and  ECAD  wrappers  and  shows  how  system 
parameters  like  cost  and  mass  can  be  rolled-up  across  multiple  system/subsystem  levels  and 
used  to  auto-verify  requirements  (by  also  applying  CT-7  concepts),  thus  demonstrating 
executable  traceability  from  the  top-level  system  model  down  to  the  lowest-level  domain- 
specific  model  (ECAD  and  MCAD  in  this  case). 


CT-14.3  System  mission  design  (and  LVC  sims):  AGI  STK 

Example:  Satellite  orbit/trajectory  &  ground  station  system  design.  The  purpose  of  this  test  case 
was  determine  if  SysML  could  help  V&V  the  more  traditional  types  of  live/virtual/constructive 
(LVC)  simulations.  AGI  STK  is  a  commercial  LVC  simulation  toolkit  and  environment  that  is 
widely  used  in  industry  and  government  (see  Slides  CT-14-9  and  -10)  .  While  its  origins  are  in 
satellite  orbit/trajectory  design  and  simulation,  today  it  is  employed  in  a  wide  variety  of 
applications  ranging  from  ISR  to  electronic  communications. 

In  this  project  we  developed  a  prototype  plugin  interface  between  SysML  (MagicDraw) 
and  STK.  This  initial  plugin  supports  two-way  interoperability  during  simulation  run-time, 
where  the  inputs  (from  SysML  to  STK)  are  indicated  by  the  blue  arrows  (Slide  CT-14-11)  and  the 
outputs  are  the  red  arrows.  The  test  case  simulation  involves  an  earth -orbiting  satellite  and  two 
ground  stations  (one  in  South  America  and  one  in  Australia  as  their  initial  locations). 

STK  automatically  displays  a  graphical  link  and  calculates  communication  link  duration 
for  each  communications  occurrence  (i.e.,  for  each  period  that  the  satellite  has  line-of-sight 
contact  with  one  or  both  ground  stations).  The  user  can  change  ground  station  and  orbit  design 
parameters  in  the  SysML  model  (e.g.,  changing  orbit  inclination  angle,  ground  station  position 
and  elevation,  and  so  on)  and  immediately  see  the  effect  on  simulation  visualization  and  link 
duration  results. 

The  plugin  reads  communication  link  durations  and  updates  the  SysML  model  instance 
after  each  communication  link  occurrence  is  done.  Slide  CT-14-12  shows  how  this  updated 
instance  can  then  be  used  as  part  of  the  higher  level  systems  context  just  like  all  the  other 
examples  in  this  report.  In  particular  you  can  run  SysML  parametric  calculations  on  the  link 
durations  for  purposes  including  requirements  verification  and  simulation  validation.  For 
example,  an  SME  might  do  this  test  to  see  if  the  simulation  behaves  as  expected:  Make  the 
satellite  going  in  an  orbit  around  the  equator  by  setting  inclination  angle  to  zero.  Then  the  link 
duration  times  should  remain  constant  (within  simulation  round-off  error)  since  the  lines-of- 
sight  should  be  constant.  We  can  capture  this  type  of  SME  knowledge  as  automated  test  cases 
and  run  them  to  help  V&V  the  simulation. 

Thus  this  test  case  demonstrates  how  SysML  can  also  be  effective  for  M&S  V&V  for 
traditional  LVC-type  environments  (with  this  example  being  more  of  the  constructive  type). 
Future  project  phases  could  further  test  and  demonstrate  this  capability  with  varieties  of  each 
LVC  type  using  a  similar  approach. 
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CT-1 5  Automated  verification  tests  on  physical  systems 

Related  MIM  pattern(s):  ao,  bo 

This  section  introduces  how  it  is  also  possible  for  SysML  models  to  aid  in  doing  V&V  on  physical 
systems  themselves  (in  addition  to  V&V’ing  the  design  and  simulation  models  of  that  physical 
system,  as  the  cases  above  are  focused  on). 


CT-15.1  Activity-based  test  scripts  with  mobile  robotics 

Example:  Rover  functionality  scenarios  (sensors,  camera,  ...).  The  slides  show  a  small  rover 
system  that  is  used  at  several  universities  for  computer  science  education  purposes  (see 
www.roboteducation.org).  We  adopted  this  rover  platform  ~2  years  ago  for  SysML  research  and 
education  purposes,  namely  by  adding  a  plugin  to  MagicDraw  so  that  you  can  operate  a  rover  as 
prescribed  by  your  own  user-created  SysML  activity  models. 

Because  we  can  both  control  the  inputs  to  the  rover  and  read  outputs  from  the  rover 
(such  as  battery  level,  light  sensor  levels,  camera  images,  etc.),  we  can  similarly  use  SysML 
activities  to  automate  at  least  some  types  of  V&V  on  one  or  more  actual  physical  rovers.  For 
example,  we  could  make  the  rover  travel  10  repetitions  of  a  prescribed  path  and  verify  that  the 
battery  level  drop  is  within  an  expected  range. 

We  could  also  use  this  approach  to  help  V&V  M&S  models  about  the  rover.  For  example, 
we  could  have  a  model  that  predicts  battery  level  drops,  then  we  could  auto-run  several  rovers 
and  read  in  actual  measurements  of  battery  level  and  compare  model  results  vs.  measurements 
to  help  validate  the  model.  Thus  this  example  illustrates  an  additional  capability  dimension 
beyond  using  SysML  to  manipulate  or  wrap  just  the  M&S  model  itself. 


3.4  Higher-level  concepts -round3 

This  section  covers  additional  concepts  that  build  upon  and  extend  the  above  concepts. 


CT-1 6  MIM:  an  architecture  for  M&S  patterns 

This  section  highlights  an  architecture  for  generalized  model  interoperability  patterns  that  are 
becoming  increasingly  evident  based  on  experiences  from  our  INCOSE  MSI  team  testbeds  and 
related  work  [Peak  et  al.  2009;  Peak  et  al.  2007].  This  section  outlines  this  emerging 
architecture,  denoted  MIM  (model  interoperability  method),  which  builds  on  both  past  [Peak  et 
al.  1998;  Tamburini  et  al.  2005]  and  current  research.  By  understanding  and  recognizing  these 
patterns,  one  can  more  effectively  plan,  specify,  design,  implement,  verify,  deploy,  and  maintain 
heterogeneous  modeling  environments  (such  as  Figure  1)  in  a  wide  variety  of  contexts  (i.e., 
beyond  excavators),  together  with  the  corresponding  model-based  engineering  practices. 
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MIM  applications — diverse  examples 

Slide  CT-16-1  lists  diverse  applications  of  the  MIM  approach  to  date,  and  several  are  illustrated 
in  the  next  several  slides  (most  using  a  composable  object  notation  which  pre-dated  SysML  and 
provided  the  primary  basis  for  SysML  parametrics).  We  highlight  two  applications  here. 

MIM  applications — excavator  systems 

Figure  i(a)  illustrates  an  excavator  testbed  in  a  recent  project  that  demonstrates  the  MIM 
approach  (Peak  et  al.  2009).  Three  distinct  categories  of  commercial -off-the-shelf  (COTS)  tools 
are  employed:  SysML  tools,  traditional  descriptive  tools  (product  CAD,  factory  CAD,  and  Excel), 
and  traditional  analysis  tools  (Excel,  FEA,  math  solvers,  and  simulation  solvers).  In  addition, 
the  project  team  developed  the  necessary  interfaces  to  integrate  the  SysML  modeling  tools  and 
other  tools  using  a  combination  of  COTS  interfaces  (e.g.,  VIATRA/MOFLON  and  ParaMagic®) 
as  well  as  custom  interfaces  developed  in  C#,  Java,  and  Visual  Basic. 

Figure  i(b),  also  given  as  Slide  CT-16-2,  illustrates  the  resulting  models  and  model 
interfaces  from  a  MIM  model  interoperability  patterns  perspective.  These  patterns  are  key 
enablers  for  platform-based  engineering  (PBE)  and  model-based  engineering  (MBE).  On  the 
left  are  COTS  descriptive  tools  (labeled  ao),  and  on  the  right  are  COTS  solver  tools  (labeled  eo). 
The  models  in  the  middle  boxes  (labeled  bo,  co,  and  do)  are  implemented  as  SysML  models 
(Figure  2).  The  box  labeled  bo  is  the  federated  systems  model  which  is  a  descriptive-type  model 
that  collects  together  various  ao-type  models  and  augments  them  where  needed.  In  this  testbed 
the  bo  model  combines  both  the  system-of-interest  (excavator  products)  and  its  manufacturing 
system.  Throughout  the  project,  reusable  analysis  and  simulation  building  blocks  that  are 
context-independent  (generic)  were  identified  and  collected  into  libraries,  as  illustrated  in  the 
PBE-oriented  box  labeled  do.  Each  context-specific  simulation  model  in  Figure  i(b)  (box  labeled 
co)  applies  selected  generic  do  building  blocks  to  the  bo  system  for  a  specific  purpose— typically 
to  calculate  values  to  verify  one  or  more  requirements  or  performance  objectives. 

Each  co  model  is  executed  utilizing  one  or  more  eo  solvers,  which  are  typically  general 
purpose  COTS  solvers,  but  may  also  be  specialized  company-proprietary  codes.  The  co  model 
pattern  is  the  focal  point  for  capturing  knowledge  about  domain-specific  analysis  intent 
including  idealization  decisions.  Depending  on  the  nature  of  the  bo  system  aspect  being 
analyzed,  these  co  models  range  from  fixed  topology  analysis  templates  (which  analysts  create 
directly)  to  variable  topology  analysis  templates  (which  auto-generate  a  model  with  simulation 
topology  that  is  specific  to  a  particular  design  instance).  In  our  excavator  testbed  the  boom 
linkage  models  are  examples  of  the  former,  and  the  dig  cycle  hydraulics  model  is  the  latter.  Each 
arrow  in  Figure  i(b)  represents  a  specific  interface  that  required  development,  implementation, 
and  testing  by  the  project  team.  SysML  modeling  and  interface  development  represented  the 
major  part  of  the  R&D  effort  for  the  project.  To  demonstrate  the  model  integration  illustrated  in 
Figure  i(b),  a  series  of  scenarios  were  created  for  the  excavator  example.  Figure  2  contains 
several  thumbnail  highlights  from  these  scenarios  (see  the  project  report  [Peak  et  al.  2009]  for 
further  explanation).  The  initial  scenario  represents  a  design  requirement  (a  target  rate  for 
moving  dirt),  and  a  marketing  requirement  (a  target  rate  for  selling  excavators).  The  hydraulic 
and  structural  teams  exercised  a  design  process  to  achieve  a  satisfactory  product  design,  and  the 
manufacturing  team  translated  the  design  into  a  manufacturing  plan,  capacity  plan,  and 
operational  plan.  The  design  process  was  then  confronted  with  changed  requirements.  A  higher 
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required  rate  for  moving  dirt  was  found  to  necessitate  a  redesign  of  both  the  hydraulic  and  the 
structural  subsystems;  this  revised  product  design  then  required  a  redesign  of  the 
manufacturing  process.  Finally,  a  higher  target  sales  rate  required  a  further  redesign  of  the 
manufacturing  process  to  support  the  corresponding  increased  manufacturing  rate. 

Per  these  foundational  results,  we  demonstrated  how  to  bridge  a  SysML  system 
specification  and  design  model  with  multiple  engineering  analysis  and  dynamic  simulation 
models— i.e.,  the  overall  excavator  project  objectives  was  met  and  exceeded.  The  significance  of 
these  results  is  not  just  in  any  single  design  decision  or  supporting  engineering  analysis— all  of 
these  could  be  done  individually  without  the  SysML  modeling  and  interface  development,  albeit 
via  ad-hoc  less  effective  means.  Rather,  the  significance  is  in  the  formal  capture  of  modeling 
and  design  knowledge  in  a  manner  that  enhances  both  design  and  analysis  integration  and 
knowledge  and  information  reuse.  Integration  fully  or  partially  automates  time-consuming 
manual  processes  and  thus  enables  faster  design  analyses  with  less  effort  by  the  designer,  which 
can  result  in  both  faster  design  cycles  and  increased  design  analysis  and  trade  space  exploration. 
Knowledge  capture  and  reuse  enhances  the  capability  of  designers  in  terms  of  both  design  speed 
and  design  quality.  The  impact  of  improved  model  management  is  better  visibility  and 
communication  across  the  entire  design/manufacturing  cycle,  leading  to  fewer  errors,  earlier 
problem  identification,  and  faster  problem  resolution. 

This  knowledge  capture,  integration,  and  reuse  occurs  at  two  levels.  First,  at  the  domain 
level,  knowledge  capture  takes  the  form  of  libraries  of  concepts,  modeling  elements,  and 
interfaces  that  are  directly  reusable  in  the  design  of  other  excavator  products  or  other  excavator 
manufacturing  processes  (and  often  in  other  domains  beyond  excavators).  The  use  of  these 
libraries  does  not  necessarily  require  expertise  in  SysML,  i.e.,  the  captured  knowledge  can  be 
accessed  by  potential  users  in  “wizard”  forms  or  in  tools  with  which  they  already  are  familiar. 
Second,  the  captured  knowledge  takes  the  form  of  explicit  system  models  that  integrate  the 
design  across  multiple  product  design  disciplines  and  between  product  design  and 
manufacturing.  The  demo  scenarios  show  how  knowledge  is  captured  and  enables  veiy  rapid 
and  inexpensive  redesign  of  both  the  product  and  its  manufacturing  processes. 

MIM  applications — linkage  system  tutorial 

Slides  CT-16-10  onward  illustrate  the  MIM  architecture  and  its  main  patterns  using  a 
comprehensive  linkage  system  tutorial.  This  tutorial  is  based  on  the  seminal  SysML  parametrics 
papers  by  Peak  et  al.  [2007,  Parts  1  &  2]  plus  updates  to  use  the  newer  more  generalized  MIM 
terminology  (vs.  the  earlier  MRA  terminology,  which  was  focused  on  patterns  for  design- 
analysis  integration  [Peak  et  al.  1998]).  Bajaj  et  al.  [2011]  describe  the  SLIM  approach,  which 
could  be  viewed  as  a  superset  context  for  MIM. 

MIM  objectives 

From  one  perspective,  the  main  objective  of  MIM  is  that  it  should  specify,  design,  implement, 
and  verify  the  interfaces  needed  to  support  model  interoperability  throughout  the  system 
lifecycle.  It  may  also  include  how  the  overarching  MBSE  method  should  apply  the  interface  to 
achieve  the  purpose.  This  perspective  provides  an  entry  point  where  people  may  often  start  by 
answering  the  question  "how  do  I  connect  model  type  A  to  model  type  B?". 

For  example  if  someone  has  a  different  SysML  tool  (e.g.,  Rhapsody)  and  a  different 
modeling  application  to  tie  to  their  SysML  model  (e.g.  STK),  then  they  could  look  to  MIM  to 
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guide  them  how  to  connect  these  tools  and  associated  models.  I.e.,  they  could  use  MIM  to 
specify,  design,  implement  and  verify  an  interface  between  Rhapsody  and  STK  to  support 
interoperability  between  a  SysML  model  in  Rhapsody  and  an  analysis  model  in  STK.  MIM  may 
also  provide  guidance  as  to  how  the  models  are  developed  in  both  tools  to  support  their 
interoperability. 

From  a  broader  perspective,  MIM  addresses  higher-level  objectives  including  capturing, 
managing,  and  reusing  modeling  &  simulation  (M&S)  knowledge  (e.g.,  modeling  intent), 
achieving  greater  degrees  of  automation,  increasing  modularity  and  reusability,  and  so  on.  The 
“Enabling  Capabilities”  column  in  the  table  in  Slide  1-27  identifies  specific  aspects  that  MIM 
aims  to  achieve.  The  “Primary  Objectives”  portion  of  this  table  identifies  candidate  ultimate 
objectives:  reducing  time,  cost,  and  risk,  as  well  as  increasing  understanding,  corporate 
memory,  and  artifact  (system)  performance. 

From  this  perspective  one  can  consider  modeling  and  simulation  environments  such  as 
the  excavator  testbed  (Figure  1)  to  be  systems  themselves.  Then  aspects  of  the  table  in  Slide  1-27 
can  be  viewed  as  potential  measures  of  effectiveness  for  such  systems,  and  similar  MBSE 
principles  can  be  applied.  Tamburini,  Peak,  Paredis  et  al.  [2005]  took  one  of  the  initial  steps 
towards  this  end  and  identified  12  capabilities,  15  challenges,  31  use  cases,  and  46  requirements 
for  such  environments. 

Structural  aspects 

One  main  facet  of  MIM  is  its  structure,  which  deals  with  what  kinds  of  things  are  included  in 
MIM  and  what  are  their  relationships  to  each  other.  Specific  structural  aspects  which  may  be 
elaborated  in  future  work  include: 

•  Describing  emerging  patterns  based  on  Figure  1  (a)  and  (b),  and  associated  refactoring  that 
may  be  needed. 

•  Including  a  description  of  the  two  main  interface/ wrapper  approaches  that  this  work  has 
manifested: 

o  Approach  1:  “connect  to  a  subset  of  an  existing  model” 

(e.g.,  XaiTools  and  NX) 

o  Approach  2:  “fully  auto-generate  solver  model,  use  it,  dispose  it” 

(e.g.,  XaiTools  and  Mathematical 

The  need  for  multiple  meta-levels  of  MIM  is  also  becoming  evident  (similar  to  UML  and  MDA 
meta-levels): 

•  A  concept-level  MIM  model  (for  methodologists/architects)  that  is  abstract  and  normalized. 

•  Implementation-level  MIM  models  (for  end  users)  that  provide  convenient  building  blocks 
and  ready-to-use  leaf-level  capabilities. 

Process  and  workflow  aspects 

Another  main  facet  of  MIM  deals  with  the  processes  and  workflows  for  creating  and  using  MIM- 
based  environments.  Here  are  a  few  such  considerations  that  may  be  further  developed  in 
future  work: 

•  Include  a  process  model  describing  MIM  in  terms  of  identifying  patterns,  composing 
models,  specifying  interfaces,  realizing  interfaces,  and  so  on.  In  general,  describe  how  to 
start  using  the  MIM  approach  in  Company  X  (i.e.,  in  environments  beyond  the  excavator 
testbed). 
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•  Help  answer  questions  such  as  “If  I  want  to  do  Y  in  a  similar  testbed/environment,  what  is 
the  sequence  of  decisions  and  actions  that  I  need  to  go  through?”  For  example: 

o  Check  if  an  interface  to  the  solver  you  need  to  use  exists,  if  not,  get  it  developed;  if  so, 
here  is  how  you  use  it  on  your  design  problem  ... 

•  Answer  such  questions  at  a  high-level  (it  may  help  to  assume  an  existing  environment  is 
already  seeded  and  in  place). 

•  Consider  these  main  roles  (types  of  actors)  that  are  needed  to  utilize  MIM,  including  the 
following  (see  elaboration  below  for  SysML  parametrics  end  users): 


Roles  (use  case  actors) 

Example  use  cases 

Template  end  user 

Uses  pre-wired  cO  template  regularly  on  new  designs 

SysML  template/simulation  author/user 

Creates  new  type  of  cO  template  using  dO/eO 

Generic  building  block  librarians 

Creates/updates/dO  libraries 

Interface  developers/integrators 

Creates/maintains  new  aO-bO  i/f,  new  eO  i/f,  ... 

M&S  environment  system  managers 

Decides  what/when  new  aO/eO  tools  added,  ... 

Each  of  these  roles  has  associated  process  models  that  can  be  quite  different  from  one 
another. 

•  It  may  also  help  to  contrast  with  examples  from  other  testbeds  and  approaches  (e.g.  different 
MIM-based  approaches  used  for  a  wafer  fab  manufacturing  simulation  testbed  vs.  for  this 
excavator  manufacturing  simulation  testbed). 

For  example,  we  have  found  it  helpful  to  differentiate  among  several  types  of  end  users  who 
work  with  SysML  parametrics  as  follows  (e.g,  with  specific  pointers  for  people  using  MagicDraw 
and  ParaMagic  in  this  case).  This  differentiation  also  helps  decompose  a  complex  topic  area  and 
define  levels  of  learning  that  can  be  incrementally  achieved. 

•  Type  l  User:  Someone  who  works  with  an  existing  co  model  template  (including  executing  it 
and  performing  additional  instance-oriented  interactions  such  as  solving,  modifying  values, 
changing  causalities,  and  re-solving). 

o  This  type  of  user  needs  the  least  amount  of  SysML  and  parametrics  know-how. 
o  This  a  good  place  to  start  for  the  casual  user,  for  someone  wanting  to  do  basic  demos,  or 
someone  just  beginning  to  explore  SysML  parametrics. 

•  Type  2  User:  Someone  who  modifies  the  structure  of  an  existing  co  model  template  and/or 
creates  new  instances. 

o  This  type  of  user  requires  more  know-how. 

o  They  also  need  a  fair  amount  of  MagicDraw  SysML  tool-aided  modification  support  (in 
some  respects  more  than  Type  3  users,  because  they  have  to  know  how  to  migrate  existing 
models  and  keep  things  consistent), 
o  This  is  a  good  step  towards  becoming  a  Type  3  user. 

•  Type  3  User:  Someone  who  creates  their  own  co  model  structures  and  instances  from 
scratch  (and/or  from  pre-existing  building  blocks  from  a  library).  May  drive  need  for 
new/updated  do  and  ao/bo  capabilities. 

o  This  type  of  user  requires  a  fair  amount  of  know-how  and  needs  good  MagicDraw  SysML 
support. 

•  Type  4  User:  Someone  who  creates  do  building  block  libraries  that  Type  2  and  Type  3  users 
can  utilize  (which  may  also  drive  interfaces  to  new  eo  tools). 
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o  This  type  of  user  requires  similar  skills  as  Type  3,  but  with  a  bent  towards  making  their 
work  reusable  and  modular,  as  well  as  providing  good  documentation  and  rigorous 
validation. 

Here  is  a  specific  example  illustrating  these  user  types  in  for  SysML  parametric  models  (a  subset 
of  technology  employed  by  MIM):  the  First  Pass  section  in  the  ParaMagic  Users  Guide  provides 
a  quick  introduction  for  Type  1  users.  After  completing  the  First  Pass,  users  can  work  at  the  Type 
1  level  with  all  the  pre-built  tutorial  models  and  examples  provided  in  ParaMagic.  After 
completing  the  First  Pass,  they  also  have  a  good  “big  picture”  basis  to  proceed  with  the  step-by- 
step  ParaMagic  tutorials.  After  completing  the  tutorials,  they  have  achieved  a  good  foundation  to 
work  as  a  Type  3  user.  Becoming  a  Type  4  user  requires  different  skills  and  know-how. 

VV&A  applications 

At  the  beginning  of  each  concept  section  above  (CT-xx)  we  have  indicated  which  MIM  patterns 
are  related  to  that  concept  (and  also  in  the  text  by  [MIM  pattern  yy]  markings).  Thus,  W&A  use 
cases  can  be  considered  as  one  subset  of  use  cases  that  the  MIM  architecture  facilitates.  In  other 
words,  the  comprehensive  and  holistic  infrastructure  enabled  by  MIM  as  described  above 
provides  a  rich  SysML-enabled  context  for  W&A  as  well  as  other  system  lifecycle  activities. 


CT-1 7  Other  concept  extensions 

Given  the  above  concepts  and  examples  as  a  basis,  this  section  describes  other  concepts  that  we 
believe  can  be  readily  supported  via  similar  means.  We  recommend  future  project  phases  to 
help  explore  and  demonstrate  these  capabilities  via  specific  test  cases. 


CT-1 7.1  Auto-generating  documents  from  SysML  models  to  support  VV&A 

SysML  authoring  tools  like  MagicDraw  typically  support  various  means  for  auto -generating 
reports  and  other  documents  based  on  model  content.  Zamparelli  and  Karban  [2010]  describe 
this  approach  for  various  documents  needed  by  traditional  stakeholders  in  the  development  of 
large-scale  ground-based  telescopes.  Cole  et  al.  [2010]  highlight  a  related  approach  for  space 
systems  specifications  and  other  documents.  This  “model-based  documentation”  technology 
can  be  similarly  applied  to  aid  W&A  for  M&S,  including: 

•  Generating  verification  traceability  and  status  reports. 

•  Generating  validation  traceability  and  status  reports. 

•  Generating  accreditation  documents. 


CT-1 7.2  Managing  accreditation  workflows  and  artifacts 

Building  on  the  ideas  in  CT-17.1,  SysML  can  also  help  in  formalizing  and  managing  workflows 
(and  related  artifacts)  like  those  in  the  M&S  accreditation  process.  NASA  JPL  did  something 
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like  this5  for  processes  in  the  Constellation  program  to  effectively  accredit  that  related  systems 
would  perform  as  expected.  By  implementing  this  capability  as  a  tool  plugin  in  MagicDraw 
SysML  tool,  they  were  able  not  only  to  passively  visualize  the  workflow,  but  also  to  actively 
manage  and  re-define  workflows  including  updating  activity  status  and  artifact  issues.  While 
their  application  was  different  than  the  DoD  M&S  accreditation  process,  it  demonstrated  the 
applied  technologies  for  such  problems  and  the  resulting  value  and  benefits. 


CM  7.3  Aiding  M&S  validation  via  test  results  data  capture  and  comparator  usage 

One  type  of  M&S  validation  process  is  running  tests  on  physical  systems  and  then  ensuring  that 
the  simulation  re-produces  similar  results  to  a  reasonable  degree.  SysML  can  help  with  at  least 
some  aspects  of  this  in  the  case  of  quantitative  measurements.  For  example,  if  you  have  a  model 
that  predicts  the  internal  steady-state  temperatures  of  communications  gear  under  various 
operating  conditions,  you  can  run  experiments  on  physical  specimens  and  capture  those 
measurements  in  a  SysML  model.  You  can  wrap  your  model  using  a  CT-13-like  concept  [MIM 
pattern  eo]  and  then  apply  comparator  building  blocks  (CT-6)  to  automatically  compare  your 
model  results  with  the  measured  results  and  auto-verify  if  the  deltas  conform  to  acceptable  limit 
requirements  (using  extensions  to  CT-8  and  applying  CT-7). 


CM  7.4  Capturing  SME  validation  criteria  for  future  automated  re-validation  usage 

Another  type  of  M&S  validation  process  is  having  subject  matter  experts  (SMEs)  evaluate  your 
simulation  by  putting  it  through  its  paces,  looking  for  holes,  and  pushing  it  to  its  limits  (i.e., 
trying  to  break  your  simulation).  At  least  some  aspects  of  what  these  SMEs  do  is  this:  they  put 
the  simulation  into  a  known  state  and  then  verify  that  the  simulation  responds  in  an  expected 
way  (e.g.,  see  the  constant  equatorial  orbit  example  in  CT-14.3  for  an  STK-based  simulation, 
where  resulting  ground  station  linkage  durations  are  then  expected  to  be  constant). 

When  you  recognize  and  capture  these  types  of  SME  validation  tests,  they  then 
effectively  become  verification  tests  that  you  can  run  own  your  own  thereafter.  Thus,  you  can 
then  employ  the  appropriate  auto-verification  concept  (from  CT-7  through  CT-15)  and  create  an 
automated  “virtual  SME”  validation  suite.  Thereafter  whenever  you  change  your  simulation  (e.g, 
before  releasing  a  new  version)  you  can  ensure  it  passes  this  validation  suite. 

Of  course  this  does  not  replace  the  need  for  actual  SME-based  validation  processes,  as 
SMEs  will  surely  do  new  things  that  you  did  not  capture  (over  time  you  can  capture  more  of 
what  they  do  and  enhance  your  “virtual  SME”  validation  suite),  as  well  as  do  some  things  that 
are  difficult  if  not  impossible  to  quantify  and  capture.  But  with  this  approach  at  least  you  can 
capture  and  automate  some  SME  validation  aspects  and  thereby  catch  related  issues  earlier  and 
more  effectively. 


5  Systems  Engineering  Process  for  Operations  Definition  (SEPOD)  Independent  Analysis  Team 
(IAT)  tool  for  managing  Mission  Operations  Architecture  Description  Document  (MO  ADD) 
generation  and  review  (as  seen  via  demos  and  personal  communications  Feb  2010). 
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CT-17.5  Managing  simulation  data  flow  and  data  pedigree  (for  sim  inputs/outputs) 

Some  simulation  environments  involve  a  complex  network  of  data  flows  in-to  and  out-of  various 
sources  and  tools  that  can  span  multiple  organizational  boundaries  (e.g.,  in  the  NASA  GRAIL6 
project  that  involves  multiple  NASA  centers  and  contractors).  Sometimes  these  flows  are  not 
well-understood  or  well-documented,  thus  making  it  difficult  to  W&A  the  simulations  involved. 

SysML  can  help  at  a  basic  level  by  treating  the  simulation  environment  as  a  system  and 
simply  documenting  its  flows  in  a  formalized  manner  (e.g.,  by  using  SysML  block,  flow, 
parametrics,  and  activity  constructs).  This  alone  can  provide  key  benefits  including  improved 
data  pedigree  and  version  control.  A  more  sophisticated  level  is  using  the  SysML  model  not  just 
as  documentation  but  as  the  means  to  execute  and  control  the  simulation  tool  chain  (similar  to 
the  SysML  parametrics  and  activity  examples  above  in  CT-13  and  CT-15). 


CM  7.6  Managing  models  &  simulations  themselves  as  systems  using  SysML  (with 
requirements,  structure,  behavior,  etc.) 

Building  on  the  previous  concept  (CT-17.5),  you  can  consider  an  M&S  environment  itself  (and  its 
components)  to  be  a  system  composed  of  subsystems  and  building  blocks.  You  can  then  apply 
systems  engineering  concepts  to  M&S  itself  (including  requirements,  structure,  and  behavior) 
and  manage  the  M&S  lifecycle  (including  W&A  processes)  using  SysML-based  MBSE/MBE 
technology  (and  reap  similar  benefits). 


6  http://science.nasa.gov/missions/grail/ 
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4  Summary  &  Recommendations 


The  above  17+  main  concepts  and  associated  examples  provide  a  sampler  of  W&A  use  cases 
along  multiple  system  dimensions  including  system  levels,  tools,  methods,  and  lifecycle  phases. 
We  leveraged  software  V&V  concepts  like  those  seen  in  JUnit  and  showed  how  to  create  and 
utilize  fundamental  building  blocks  to  make  V&V  for  M&S  more  iterative  and  ubiquitous 
throughout  the  system  lifecycle.  Altogether  this  evidence  demonstrates  how  a  SysML  and  MBSE 
approach  is  highly  capable  in  terms  of  both  breadth  and  depth. 

In  summary  we  achieved  the  primary  objective  of  this  quick-look  Phase  1  project  (Slide  4-2): 

•  We  showed  how  W&A  can  be  made  more  model-based,  more  embedded,  and  more 
automated  so  that  W&A  can  occur  more  incrementally  and  iteratively  throughout  the 
lifecycle  (vs.  after-the-fact  as  is  often  done  today  in  a  document-based  checklist  manner). 

Along  the  way  we  also  achieved  these  supporting  secondary  objectives: 

•  Applied  known  M&S  patterns  and  developed  new  patterns  where  needed. 

•  Demonstrated  the  approach  by  extending  existing  testbeds  and  examples. 

•  Provided  a  basis  for  developing  DoD-specific  testbeds  and  deploying  technology  for  DoD 
programs  in  future  phases.  See  the  recommended  Deployment  Roadmap  in  Slides  4-5 
through  4-7. 

We  recommend  these  next  project  phases  to  accelerate  progress  along  the  roadmap: 

•  Phase  2  (proposed  for  FYll ):  Demonstrate  SysML-based  W&A  approach  in  DoD-relevant 

prototype  testbeds.  In  particular,  apply  this  approach  to  develop  a  SysML-based 
architecture  for  a  current  modeling  activity  of  interest  to  the  sponsor  such  as  under  body 
blast  (UBB)  or  similar  efforts.  In  parallel  pursue  technical  advancements  per  research 
needs  seen  in  Slide  4-8. 

•  Phase  3+  (proposed  for  FY12+):  Develop  multi-language/multi-technology  ecosystem 

architecture  combining  AADL  &  SysML  capabilities  plus  related  diverse  tools  as 
examples 

The  main  benefits  we  envision  from  this  proposed  multi-phase  effort  and  subsequent 
deployments  are  the  following  (see  also  Slide  4-4): 

•  Enable  significant  improvements  via  new  methods  that  make  W&A  much  more 
embedded  and  automated  throughout  the  lifecycle,  thereby: 

o  Increasing  knowledge  capture  and  completeness, 
o  Increasing  modularity  and  reusability, 
o  Increasing  traceability. 

o  Reducing  manual  effort  and  associated  errors, 
o  Increasing  automation  and  consistency. 

•  Utilize  these  technical  capabilities  to  reduce  cost/time/risk  and  increase  understanding, 
corporate  memory,  and  system  performance. 

•  Provide  examples  and  reference  implementations  so  that  the  DoD  supply  chain  can 
begin  to  learn  and  apply  these  approaches. 

•  Provide  demos  of  how  the  philosophy  and  techniques  could  be  transferred  and  utilized  to 
impact  the  DoD  acquisition  lifecycle. 
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Some  of  this  material  is  taken  from  our  copyrighted  ©  material  that  was 
pre-existing  and/or  has  been  produced  with  non-SERC  funding. 

For  example,  this  slide  template  indicates  slides  taken  from  our 
SysML/MBSE  short  course  series  (see  footer  below). 

SERC  sponsors  and  SERC  collaborators  are  welcome  to  use  any  or  all  of 
these  slides  (as-is  or  adapted)  if  you  will  please  do  this: 

-  If  used  as-is:  Add  this  usage  permission  note  near  the  bottom: 

Material  copyrighted  ©  by  Georgia  Tech  and  InterCAX  LLC.  Used  by  permission. 

-  If  adapted/modified:  Add  this  usage  permission  note  near  the  bottom: 

Adapted  from  material  copyrighted  ©  by  Georgia  Tech  and  InterCAX  LLC.  Used  by  permission. 


Full  Disclosure:  Georgia  Tech  &  InterCAX  LLC 

(excerpted  from  short  course  context) 


This  course  material  is  developed  jointly  by  Georgia  Tech  and  InterCAX  LLC. 

This  course  material  presents  products,  tools,  and  examples  that  are  developed 
by  InterCAX  and/or  Georgia  Tech. 

The  intent  is  to  present  vendor-independent  concepts  and  examples  in  an  objective 
educational  way  that  the  course  participants  will  find  helpful.  References  are  made  to 
commercial  products  by  InterCAX  and  non-commercial  tools  by  Georgia  Tech  for  the 
purpose  of  making  these  concepts  concrete.  Course  participants  are  responsible  to 
evaluate  these  products  and  tools  for  themselves  and  to  investigate  similar  products  and 
tools  by  other  organizations  where  applicable. 

Note  that  Dr.  Russell  Peak  (an  instructor  in  this  course  and  a  member  of  the  Georgia 
Tech  research  faculty)  has  a  business  interest  in  InterCAX  LLC  per  the  following: 
InterCAX  LLC  is  a  spin-off  company  that  has  commercialized  technology  from  Dr.  Peak’s 
Georgia  Tech  group.  Georgia  Tech  has  licensed  technology  to  InterCAX  and  has  an 
equity  stake  in  the  company.  Dr.  Peak  is  one  of  several  business  partners  in  InterCAX. 
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GIT  Project  Team  -  RT21 

•  Research  Professionals 

-  Selcuk  Cimtalay,  PhD 

-  Russell  Peak,  PhD  (PI) 

-  Andy  Scott 

-  Miyako  Wilson 

•  Undergraduate  Research  Assistants 

-  Brian  Aikens 

-  Drew  Martin 

•  Vendor  Collaborators,  especially: 

-Analytical  Graphics,  InterCAX,  and  No  Magic 

Georgia 

Tech 

Part  11  d 


Russell  Peak,  PhD  is  a  Senior  Researcher  at  the  Georgia  Institute  of  Technology  where  he  serves  as 
Director  of  the  Modeling  &  Simulation  Lab  ( www.msl.gatech.edu )  and  Associate  Director  of  the  Product 
&  Systems  Lifecycle  Management  (PSLM)  Center  ( www.pslm.gatech.edu ).  He  is  also  the  CTO  at 
InterCAX  LLC  ( www.lnterCAX.com ) — a  spin-off  company  that  has  commercialized  his  work  from 
Georgia  Tech. 

Dr.  Peak  specializes  in  knowledge-based  methods  for  modeling  &  simulation,  standards-based 
product  lifecycle  management  (PLM)  frameworks,  and  knowledge  representations  that  enable  complex 
system  interoperability.  Dr.  Peak  originated  the  multi-representation  architecture  (MRA) — a  collection 
of  patterns  for  CAD-CAE  interoperability — and  composable  objects  (COBs) — a  non-causal  object- 
oriented  knowledge  representation.  This  work  provided  a  conceptual  foundation  for  executable 
paramedics  in  SysML  and  for  related  technology  commercialized  by  InterCAX  in  the  Georgia  Tech 
VentureLab  program. 

After  six  years  in  industry  (Bell  Labs  and  Hitachi),  he  joined  the  research  faculty  at  Georgia  Tech. 
Since  1997  he  has  been  principal  investigator  on  30+  projects  with  sponsors  including  Boeing,  IBM, 
JPL,  Lockheed,  NASA,  Rockwell  Collins,  Sandia,  Shinko  (Japan),  TRW  Automotive,  US  DoC  (NIST) 
and  DoD.  He  has  authored  over  80  publications  (including  several  Best  Paper  awards),  holds  several 
patents,  is  an  active  member  in  ASME  and  INCOSE,  and  represents  Georgia  Tech  on  the  OMG 
SysML  task  force,  and  is  a  Content  Developer  for  the  OMG  Certified  Systems  Modeling  Professional 
(OCSMP)  program.  As  of  February  201 1  he  has  conducted  numerous  SysML  short  courses 
for  500+  professionals  {www.pslm.gatech.edu/ courses) . 

Dr.  Peak  leads  the  INCOSE  MBSE  Challenge  Team  {www.pslm.gatech.edu, / projects / incose-mbse-msi) 
for  Modeling  &  Simulation  Interoperability  with  applications  to  mechatronics  (including  mobile 
robotics  testbeds)  as  a  representative  complex  systems  domain. 

Contact:  Russell.Peak@gatech.edu 


Copyright  ©  Georgia  Tech  and  InterCAX.  All  Rights  Reserved. 
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Background 

•  Lab/Center  History  @  Georgia  Tech 

-  Engineering  Information  Systems  Lab  (1996-2006),  etc. 

-  Modeling  &  Simulation  Lab  (2006-Present) 

•  Director:  R  Peak  www.msl.gatech.edu 

-  Product  &  Systems  Lifecycle  Management  Center  (2005-Present) 

•  Director:  L  McGinnis  Associate  Directors:  C  Paredis  and  R  Peak 

•  Being  renamed:  Model-Based  Systems  Engineering  (MBSE)  Center 

•  Specializations 

-  Knowledge  representations  for  engineering  (languages,  algorithms,  ...) 

-  Modeling  &  simulation  interoperability 

-  Model-based  systems  engineering  /  engineering  /  X  (MBSE/MBE/MBX) 

•  Sample  Accomplishments 

-  Composable  objects  (became  basis  for  SysML  parametrics) 

-  MRA/MIM  patterns  for  modeling  &  simulation 

-  Commercialization  via  spin-off  company:  InterCAX  LLC 

-  Contributions  to  related  standards  (SysML,  ISO  10303,  ...) 
and  organizations  (INCOSE,  OMG,  ...) 


X-Analysis  Integration  Techniques  (c.  1993-2004) 
for  Modeling  &  Simulation  Interoperability 

httg/Zeislab.gatech.  edu/research/ 


a.  Multi-Representation  Architecture  (MRA)  b.  Explicit  Design-Analysis  Associativity 
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c.  Analysis  Module  Creation  Methodology 

Analysis  Procedures  Analysis  Module  Catalogs 
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Constrained  Object-based  Analysis  Module 

Constraint  Schematic  View 


Engineering  Information  Systems  Lab  t  eislab, gatsch.edu 
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Project  Objectives 


Representing  System  Models 

With  SysML:  Unified,  Connected,  Consistent,  Explicit 


per  updated  scope  2010-07-20 


Primary  objective 

-  Demonstrate  how  to  address  VV&A  gaps 
by  applying  SysML  and  MBSE  technology 

-  Show  in  particular  how  V&V  can  be 


more  embedded  &  automated  throughout  system  lifecycle 


•  Supporting  sub-objectives  (via  “quick-look”  approach) 

-  Apply  known  modeling  &  simulation  (M&S)  patterns 
and  develop  new  patterns  where  needed 

-  Demonstrate  approach  by  extending  existing  testbeds  and  examples 
(excavator  testbed  -  next  slide,  other  examples,  ...) 

-  Provide  basis  for  developing  DoD-specific  testbeds 

and  deploying  technology  for  DoD  programs  in  future  phases. 


•  Terminology 

-  SysML  is  the  Systems  Modeling  Language  (www.omgsysml.org),  which 
has  been  called  “the  new  global  language  of  350K+  systems  engineers” 
(amazon.com) 

-  MBSE  is  model-based  systems  engineering  (vs.  document-centric  approach) 


Relationship  to  Other  Efforts 

•  Relationship  to  other  DDR&E  efforts 

-  Per  “quick-look”  intent  (DDR&E  guidance  7/2010), 
interrelations  are  not  an  emphasis  in  this  phase 

-  Strong  potential  exists  for  key  relationships  in  the 
future  (e.g.,  other  RTs/efforts  using  SysML) 

-  Final  report  will  include  potential  ways  to 
collaborate  in  Systems  2020  and  leverage  related 
technology  (e.g.,  AADL)  and  efforts  (e.g.,  SAVI). 

•  Relationship  to  other  external  efforts 

-Ongoing  involvement  in  INCOSE  MBSE  Initiative, 
OMG  SysML  Task  Force,  etc. 

Georgia 

Tech 

[Parti]  id 
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Process  Used 

•  Enabling  bottom-u p/top-down  hybrid  approach 


-  Iterative  ubiquitous  VV&A;  building  block  VV&A 

-  Software  V&V  techniques  applied  to  systems 
(continuous  integration/builds,  JUnit,  ...) 

Leveraging  existing  examples 


Better  Ingredients. 
Better  Pizza. 


-  Illustrating  technical  approach  in  quick-look  fashion 

-  Adding  VV&A-oriented  extensions  where  needed 


•  Demonstrating  sample  VV&A  use  cases  along 
multiple  system  dimensions: 

-  system  levels,  tools,  methods,  lifecycle  phases, ... 


Georgia 

Tech 

Parti!  Ill 


Activity  2a  in  GIT  RT21  Project 

Leveraged  existing  capabilities  &  examples 


id  W&A  Concept  Example(s) 

1  1 

Core  embedded  V&V  concepts 

CT-1 

Language-level  integrity:  automated  units  consistency 

MagicDraw  SysML  detecting  units  mismatch 

CT-2 

Language-level  integrity:  automated  equation  checking 

ParaMagic  detecting  wrong  parameter  name 

CT-3 

Language-level  integrity:  other  examples 

Model  integrity  (e.g.,  multiplicity  checking); 
propagating  name  updates;  instance  updates;  etc. 

CT-4 

Augmented  language-level  integrity:  ensuring  best  practices,  etc. 

Model  checking  suites  in  MagicDraw  and  ParaMagic 

CT-5 

Leveraging  built-in  checking  by  solvers  /  external  tools  as 
wrapped  in  a  SysML  context 

Mathematica  detecting  overconstrained  system  of 
equations,  etc. 

Higher-level  concepts  -  roundl 

CT-6 

V&V  building  blocks 

Margin  block  and  comparator  block 

CT-7 

Automated  requirements  verification 

FireSat,  SimpleSat,  etc.  (parametrics,  margin,  ...) 

CT-8 

Embedded  unit  tests 

LinkageSystems,  build  block  libraries,  ... 

CT-9 

Automated  roll-up  of  embedded  unit  tests  (basic  multi-level  test) 

LinkageSystems,  HomeHeatingSystem 

CT-10 

Automated  roll-up  of  embedded  multi-level  tests 

Combining  above,  ... 

CT-1 1 

“DNA  signatures”  -  user  interaction  with  model  for  intuitive  visual 
inspection  to  aid  model  comprehension,  V&V,  debugging,  etc. 

LinkageSystems,  FireSat/NGDMC,  etc.  (and  above) 

Main  Test  Cases  (for  Project  Activities  2  and  3) 

-  Mobile  robotics  (IPRE  Scribbler  h/w  with  Myro  software  platform) 

-  Excavator  test  bed  with  linkage  systems 

-  Satellite-to-ground  station  communication  link  simulation 

-  FireSat  /  NGDMC  satellite 

-  Short  course  tutorials  (vehicle  fuel  system,  space  satellite,  ...) 

-  Home  heating  system 

V 
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Activity  3a  in  GIT  RT21  Project 

Extended  capabilities  &  examples  and  created  new  ones 


id 

W&A  Concept 

Example(s) 

Higher-level  concepts  -  round2 

CT-12 

Verification  of  external  core  solvers  via  auto-generated  native  test  models 

12.1 

Core  math  solvers:  Mathematica,  OpenModelica,  Matlab  SMT 

Unit  test  cases  (to  verify  new  solver  releases,  etc.); 

XaiTools  production  test  suite  (-150  models) 

CT-13 

Automated  verification  of  external  simulation/analysis  models/tools  via  wrapping 

13.1 

System  dynamics:  Matlab/Simulink 

HomeHeatingSystem 

13.2 

Finite  element  analysis  (FEA):  Ansys 

LinkageSystems 

CT-14 

Automated  verification  of  external  design/descriptive  models/tools  via  wrapping 

14.1 

Spreadsheets:  Excel 

Excavator  manufacturing  cost  estimator 

14.2 

CAD:  NX  (MCAD);  Expedition,  etc.,  via  AP210  (ECAD) 

Vehicle,  MiniSatellite  electronics  (as  recorded  demos) 

14.3 

System  mission  design  (and  LVC  sims):  STK 

Satellite  orbit  &  ground  station  comm.  sys.  design 

CT-15 

Automated  verification  tests  on  physical  systems 

15.1 

Activity-based  test  scripts  with  mobile  robotics 

Rover  functionality  scenarios  (sensors,  camera,  ...) 

Higher-level  concepts  -  round 3 

CT-16 

MIM:  an  architecture  for  M&S  patterns 

CT-17 

Other  concept  extensions  (which  can  be  demonstrated  using  similar  capabilities  as  above) 

17.1 

Auto-generating  documents  from  SysML  models  to  support  W&A  (for  V&V  traceability  &  status,  accreditation  reports,  ...) 

17.2 

Managing  accreditation  workflows  and  artifacts 

17.3 

Aiding  M&S  validation  via  test  results  data  capture  and  comparator  usage 

17.4 

Capturing  SME  validation  criteria  for  future  automated  re-validation  usage 

17.5 

Managing  simulation  data  flow  and  data  pedigree  (e.g.,  for  sim  inputs/outputs) 

17.6 

Managing  models  &  simulations  themselves  as  systems  using  SysML  (with  requirements,  structure,  behavior,  etc.) 

rPart  11  131 
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SysML  Technology  Status  &  Viability 

Official  Site:  www.omqsvsml.org  (Beware  of  imitations!) 


Spec  vl .0:2007-09  vl. 1:2008-11  vl .2:  2010-06  v1.3:WIP 
v2.x:  RFI  preparation  workshop  -  2008-12 

http://www.omg.org/spec/SvsML/ 

Strong  vendor  support 
Good  learning  infrastructure 

-  Books,  short  courses,  academic  courses, 

INCOSE/OMG  tutorial,  public  examples,  etc. 

OMG  Certified  Systems  Modeling  Professional 

-  http://www.omq.org/ocsmp/ 

Expanding  production  usage 

-  INCOSE  MBSE  Initiative  workshops:  2007-2011 

-  http://www.pslm.gatech.edu/events/frontiers/:  2006,  2007,  2008,  2011 

-  OMG  SysML  Info  Days:  2008-12;  IC-MBSE  2008,  2009,  2010 

Overall  Status:  Healthy  and  Growing  ©  see[Part2^ 

ms 


Curriculum  History  &  Formats  Offered 

Statistics  as  of  Feb  2011  —  www.pslm.gatech.edu/courses 

♦  Full-semester  Georgia  Tech  academic  courses 

-  ISYE  /  ME  8813  &  4803:  Since  Fall  2007  (-95  students  total) 

♦  Industry  short  courses 

-  Collaborative  development  &  delivery  with  InterCAX  LLC 

-  Multiple  [#offerings, -students]  and  formats  since  Aug  2008 

»  SysML  101  [#18,-305];  SysML  102  (hands-on)  [#14,-220] 

-  Modes:  »  Onsite  at  industry/government  locations 

»  Open  enrollment  via  Georgia  Tech  (Atlanta,  DC,  Orlando,  Vegas, ...) 
»  Web-based  “live”  since  Apr  2010 

-  Coming  soon:  105/201/205/301/305  (int/adv  concepts,  OCSMP  prep,  ...) 

♦  Georgia  Tech  Professional  Masters  academic  courses 

-  Professional  Masters  in  Applied  Systems  Engineering 

www.pmase.gatech.edu  (initiated  2009) 

-  ASE  6005  SysML-based  MBSE  course:  ea.  Summer 

-  ASE  6006  SE  Lab  (SysML-based  system  design  project)  -  ea.  Fall 
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Open  Enrollment  Short  Course  Formats 

SysML  101  (1  day),  SysML  102  (2.5  days),  plus  others  (SysML  105,  etc.) 


www.pslm.gatech.edu/courses 


DEFENSE  TECHNOLOGY 


Systems  Engineering  Certificate 


(also  for  Modeling  &  Simulation  Certificate) 


Learn  how  to  develop  a  systematic  approach  to  develop  products  to 
meet  customers’  needs  Refine  your  interdisciplinary  approach  and 
hone  the  means  to  create  a  system  that  meets  your  customers’ 
needs  Learn  how  to  analyze  user  needs  and  turn  them  into  systems 
requirements 

REQUIRED  COURSES 

•  Fundamentals  of  Modern  Systems  Engineering  (DEF  4501 P) 

•  Leading  Systems  Engineering  Teams  (DEF  4503P) 

ELECTIVE  COURSES 

(Choose  any  three  courses) 

»  Advanced  Problem  Solving  Methods  (DEF  4506P) 

»  Design  of  Experiments  (DEF  5003P) 

•  Human  Systems  Integration  (DEF  4504P) 

► »  Model-Based  Engineering  Using  SysML  Essentials  for 
Understanding  SysML  Models  (DEF  4508P) 

>  »  Model-Based  Engineering  Using  SysML  Hands-On  Essentials  for 
Creating  SysML  Models  (DEF  4509P) 

•  Modeling  &  Simulation  for  Systems  Engineering  (DEF  4003P) 

•  Systems  Design  and  Analysis  (DEF  4502P) 


2011  Offerings 

SysML  101/102 

-  Feb  22,  23-25  (Orlando) 

-Apr  5,  6-8  (DC  area) 

-  Aug  16,  1 7-1 9  (  Las  Vegas) 

-  Nov  1 , 2-4  (Atlanta) 

SysML  105 

-  May/June  (via  web  sessions) 
SysML  205 

-  Coming  soon  (-2H-2011). 


http://www.pe.gatech.edu/certificates 


Industry  Short  Course  Contents 

SysML  101:  Notation  Comprehension  Focus  ( 1  day) 


module 

topic 

Course  Context 

000.01 

Introduction  and  course  overview 

SysML  101:  Essentials  for  Understanding  SysML  Models 

101.01 

MBSE  context  &  motivation 

rvr  The  4  Pillars  of  SysML  "1 — 

Automotive  Anti-Lock  Braking  System  Example 
1.  Structure  j -  2.  Behavior 


3.  Requirements 


101.02 

SysML  introduction  &  overview;  Course  examples  overview 

101.03 

Structure  concepts:  block  basics  (bdd),  instances;  packages  (pkg) 

101.04 

Structure  concepts:  block  internals,  ports,  flows  (ibd) 

101.05 

Upfront  concepts:  use  cases  (uc);  requirements  (req) 

101.06 

Behavior  concepts:  activities,  actions  (act) 

101.07 

Behavior  concepts:  interactions/sequences  (seq);  state  machines  (stm) 

101.08 

Structure  concepts:  block  parametrics  (par) 

101.09 

Cross-cutting  SysML  concepts,  methods,  and  processes 

101.99 

Wrapup  —  SysML  101 

Report  No.  SERC-201 1-TR-018 
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Industry  Short  Course  Contents 

SysML  102:  Hands-on  Execution-Oriented  Focus  (2.5  days) 


module 

topic 

SysML  102:  Essentials  for  Creating  SysML  Models  (Hands-On  for  Tool  Users) 

102.01 

User  workstation  setup 

102.02 

Tool  familiarity  introduction  -  how  to  browse  existing  models,  etc. 

102.03 

Structure  concepts:  block  basics  (bdd),  instances;  packages  (pkg) 

102.04 

Structure  concepts:  block  internals,  ports,  flows  (ibd) 

102.05 

Upfront  concepts:  use  cases  (uc);  requirements  (req) 

102.06 

Behavior  concepts:  activities,  actions  (act)  (w/  Myro  rover  team  excercise) 

102.07 

Behavior  concepts:  interactions/sequences  (seq);  state  machines  (stm) 

102.08 

Structure  concepts:  block  parametrics  (par) 

102.09 

Cross-cutting  SysML  concepts,  methods,  and  processes 

102.10 

MBSE  processes:  model-based  document/report  generation  (Velocity,  etc.) 

102.11 

MBSE  processes:  model  repositories  /  Teamwork  Server  introduction  for  users 

102.99 

Wrapup  —  SysML  102 

Approximate  structure  for  each  main  concept  module  in  SysML  102: 

Spiral  1:  Howto  implement  basic  concepts  from  SysML  101  in  MagicDraw 

Spiral  1:  Corresponding  student  exercise 

Spiral  1:  Corresponding  Q/A 

Spiral  2:  How  to  implement  other  concepts  (from  SysML  101  and  more) 

Spiral  2:  Corresponding  student  exercise 

Spiral  2:  Corresponding  Q/A 

J  I ■  Baa  m 


Model-Based  Systems  Engineering  Using  SysML 

Excavator  Testbed  (2007-2009) 

Abstract 

This  presentation  highlights  Phase  1  results  from  a  modeling  &  simulation  effort  that  integrates  design  and  assessment  using 
SysML.  An  excavator  testbed  illustrates  interconnecting  simulation  models  with  associated  diverse  system  models,  design 
models,  and  manufacturing  models.  We  then  overview  Phase  2  work-in-process  including  a  mobile  robotics  testbed  and 
associated  SysML-driven  operations  demonstration. 

The  overall  goal  is  to  enable  advanced  model-based  systems  engineering  (MBSE)  in  particular  and  model-based  X  (MBX)  [1] 
in  general.  Our  method  employs  SysML  as  the  primary  technology  to  achieve  multi-level  multi-fidelity  interoperability,  while  at  the 
same  time  leveraging  conventional  modeling  &  simulation  tools  including  mechanical  CAD,  factory  CAD,  spreadsheets,  math 
solvers,  finite  element  analysis  (FEA),  discrete  event  solvers,  and  optimization  tools. 

This  Part  1  presentation  overviews  the  project  context  and  several  specific  components.  Part  2  focuses  on  manufacturing 
aspects  including  factory  design,  process  planning,  and  throughput  simulation. 

This  work  is  sponsored  by  several  organizations  including  Lockheed  and  Deere  and  is  part  of  the  Modeling  &  Simulation 
Interoperability  Team  [2]  in  the  INCOSE  MBSE  Challenge  (with  applications  to  mechatronics  as  an  example  domain). 

[1]  The  X  in  MBX  includes  engineering  (MBE),  manufacturing  (MBM),  and  potentially  other  scopes  and  contexts  such  as  model-based  enterprises  (MBE). 

[2]  http://www.pslm.gatech.edu/projects/incose-mbse-msi/ 

Citations 

-  RS  Peak,  CJJ  Paredis,  LF  McGinnis  (2009-04)  Model-Based  SE  Using  SysML — Part  1:  Integrating  Design  and  Assessment 
M&S.  NDIA  M&S  Committee  Meeting,  Arlington,  Virginia. 

-  LF  McGinnis  (2009-04)  Model-Based  SE  Using  SysML — Part  2:  Integrating  Manufacturing  Design  and  Simulation. 

NDIA  M&S  Committee  Meeting,  Arlington,  Virginia. 

-  Main  team  web  page:  -  These  publications: 

http://www.pslm.gatech.edu/projects/incose-mbse-msi/  http://eislab.gatech.edu/pubs/seminars-etc/2009-04-ndia-ms/ 

Contact 

Russell.Peak@gatech.edu,  Georgia  Institute  of  Technology,  Atlanta,  www.msl.gatech.edu 

_ _ _ _ _ _ _ _ _ _ _ _ _ [Part  11  20| 
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Excavator  Modeling  &  Simulation  Testbed 

Tool  Categories  View 


Traditional 
Descriptive  Tools 


NX  /  MCAD  Tool 


FactoryCAD 

|  Factory  j 
I  Layout  Model  J 


[  Production  1 

Ramps  J 


RSA/E+  /  SysML 

No  Magic  /  SysML 

'  Factory  ] 

1  Model  J 

f  Excavator  1 

.  System  Model  J 

Operational 

Scenario 

RSA/E+  /  SysML 
f  Excavator  | 
Executable 
^  Scenario  J 


Interface  &  Transformation  Tools 
(VIATRA,  XaiTools,  ...) 


Traditional 

Simulation  &  Analysis  Tools 


IfcMftWSil 

(  -tf-  1  , 

□£  . 

— ; 

^  Cost  Model 


01 


f  Dig  Cycle  'l 
I  Model  J 


(  Factory  ) 

[  Simulation  J 
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Excavator  Modeling  &  Simulation  Testbed 


Sample  Artifacts 


Broadly  Applicable  Technology 

Examples  of  Executable  SysML  Parametrics 

♦  Road  scanning  system  using  unmanned  aerial  vehicle  (UAVs) 

♦  UAV-based  missile  interceptor  system  trade  study 

♦  Space  systems  (tutorials):  orbit  planning;  mass/cost  roll-ups 

♦  Space  systems  (studies/pilots):  FireSat  (INCOSE  SSWG),  ... 

♦  Space  systems  (actuals):  science  merit  function,  ... 

♦  Environmentally-conscious  energy  systems  /  smart  grid 

♦  Manufacturing  “green-ness”  /  sustainability  assessments 

♦  Electronics  recycling  network 

♦  Regional  water  management  systems  (e.g.  South  Florida) 

Next-Generation 

♦  Mechanical  part  design  and  analysis  (FEA)  Spreadsheet  Technology++ 

(object-oriented,  multi-dimensional,  ...) 

♦  Wind  turbine  supply  chain  management 

♦  Insurance  claims  processing  and  website  capacity  model 

♦  Financial  model  for  small  businesses 

♦  Banking  service  levels  model 


Copyright  ©  Georgia  Tech  and  InterCAX.  All  Rights  Reserved.  SysML 
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Model  “DNA  Signatures”  Using  SysML  Parametrics 


Panorama  Tool  by  Modeling  &  Simulation  Lab  (www.msl.gatech.edu) 
Examples  as  of  -9/2009  —  Low/Medium  Complexity 


a.  Snowman 


b.  Mini  Snowman 


c.  Snowflake 


d.  Mouse 


e.  Cactus 


f.  ? 


Test:  Match  the  actual  model  titles  (below)  to  their  “DNA 
signatures”  with  imagined  titles  (left). 


1 .  South  Florida  water  mgt.  (hydrology)  model 

2.  2-spring  physics  model 

3.  3-year  company  financial  model 

4.  UAV  road  scanning  system  model 

5.  Car  gas  mileage  model 

6.  Airframe  mechanical  part  model 


7.  Design  verification  model 

(automated  test  for  two  Item  6.  designs) 


g.  Springy  Snowflakes 


Part  11  25l 


Recent  Models:  ^Medium  Complexity 

2010-10  Model  size  =  0(1 00s)  equations,  0(1000+)  variables 


supply  chain  metrics 

mfg.  sustainability:  airframe  wing 

electronics  recycling  network 

►  -j  • 

jf 

*  :: 

y... 

i-v 

“Turtle” 

“Tumbleweed” 

“Galaxy  with  Black  Hole” 

mfg.  sustainability:  automotive  transmissions 

2010-12: 

~20k  variables 
~15k  equations 

WIP: 

100K,  1 M,  ... 


Georgia 

Tech 


“Angler  Fish” 


[Part  1]  26| 
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SERC  Impact  Questions 

•  Who  cares? 

-  All  M&S  and  VV&A  stakeholders  (given  benefits  below) 

•  If  you're  successful,  what  difference  will  it  make? 

-  Our  approach  provides  Enabling  Capabilities  (table  rows  below), 
which  produces  Primary  Impacts 
(table  columns) 

-  Ex.  Related  earlier  studies 
achieved  75%  reduction 
in  M&S  time  and  enabled 
increased  analysis  intensity 

-  We  have  endeavored  to  demo 
basis  for  similar  benefits 
in  this  SERC  effort 
(with  quantification  targeted 
for  future  phases) 


Georgia 
Tech 

27| 


Primary  Impacts 

enterprise  MOEs 
(measures  of  effectiveness, 

methods/tools  MOPs 
(measures  of  performance) 

Enabling  Capabilities 

Reduced 

Time 

Reduced 

Cost 

Reduced 

Risk 

Increased 

Understanding 

Increased 

Corporate  Memory 

Increased  Artifact 

Performance 

Increased  Knowledge 
Capture  &  Completeness 

■ 

■ 

■ 

Increased 

Modularity  &  Reusability 

Increased 

Traceability 

■ 

■ 

Reduced 

Manual  Re-Creation 

■ 

■ 

Increased 

Automation 

■ 

■ 

Reduced 

Modelinq  Effort 

■ 

■ 

Increased 

Analysis  Intensity 

■ 

■ 

Presentation  Contents 

SERC  RT21  -  GIT  SysML-based  Approach 

•  [Part  1]  Intro  &  context 
[Part  2]  SysML  concepts:  essential  prerequisites 

•  [Part  3]  Walk-through  of  concepts  &  examples/demos 

-  Includes  SysML-based  V&V  building  blocks 

•  [Part  4]  Summary  &  Recommendations 


Georgia 

SYSTEMS  EM iJM-TIHlM.! 

Tech 

n  n  a u  u  r  l  h  Lnnlor 

[Part  21  28 
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[Part  2]  SysML  Concepts:  Essential  Prerequisites 

(highlights  from  our  SysML  101  &  102  courses) 

•  SysML  context:  system  modeling  &  general  modeling 

•  Representative  SysML  authoring  tool  (MagicDraw) 

•  Blocks  and  instances 

•  Blocks  and  equation-based  knowledge:  parametrics 

•  Other  concepts  covered  in  later  Parts  as  needed: 

-  Requirements  representation,  traceability,  verification,  ... 

-  Activities  (function-based  behavior) 

-  Automated  model-based  document  generation 

-  Collaborative  modeling  environments 

-  Healthy,  viable,  growing  technology  ecosystem 
(many  SysML  users,  tools,  support,  ...) 

Georgia 

Tech 

_ Part  21  29 


iNcos^  Pillsirs  of  SysML 

Automotive  Anti-Lock  Braking  System  Example 


3.  Requirements 


4.  Parametrics 
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Representing  System  Models 

With  SysML:  Unified,  Connected,  Consistent,  Explicit 


system  model 


operational  concepts 


Georgia 

Tech 


documents 


analysis  & 
simulation 
models 
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What  You  Can  Do  with  a  SysML  Model  ... 

System  Modeling  (and  General  Object  Modeling) 


•  Describe  requirements,  system  structure,  &  allocations 

•  Generate  and/or  link  to  simulations  &  verify  requirements 

•  Visualize  your  models;  Support  system  trade  studies 

•  Link  to  domain  models  &  analyses:  S/W,  M/ECAD, ... 

•  l.e.,  do  the  Vee  and  more  ...  (e.g.,  support  system  operation) 


Requirements 

Definition; 

System  Concepts 


o\ 

CL  Verification  Plan 


System  Spec.; 


Sys.  Integration; 

Sys.  Verification  .£> 


Allocate  Specs; 
Allocate  Verification 


Assemble  Subsys; 
Subsys.  Verification 


Design  Engineering 


Georgia 

Tech 


Time 


"Vee"  model  by  Forsberg  and  Mooz,  1992 


Representative  SysML  Tools  Used  in  RT21  Project 

commercial  tools:  MagicDraw  (base)  +  SysML  plugin  +  ParaMagic  plugin 
prototype  tools:  Georgia  Tech  BuzzToys  plugins:  MyroMagic,  Panorama,  AeroMagic 
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MagicDraw  Tool  Fundamentals 

User  Interface  Highlights 


Beyond  Pretty  Pictures:  Rich  Modeling 
Attributes  (Metadata)  in  each  SysML  Block 


[j|]  Figure  B.1 5  Defining  the  Automotive  Domain  ] 


Specification  Window 


Owned  Behavior  = 

(^jStartVehicleBlackBox 

l^jDriveBlackBox 


Q  System  -  HybridSUV 


/ 

1 - 

-vehic 

j  /  «system» 

\  «externab 

Consistent  and - - 

comprehensive  access 
to  many  model  aspects 
(attributes,  meta-attributes, ...) 


MUM* 


B  ■ 


y :  |  H  HybridSUV  [HSUVModel]  ▼  | 


ffl-E 

m 

■m 

E-l 


Documentation/Hyperlink 
Usage  in  Diagrams 
Constraints 
Attributes 

□D  +VIN  :  SysML  Profile: 
□3  +mpg  :  SysML  Profile 
□D  +payloadCapacity  :  i 
□a  +position  :  SysML  Prc 
□a  +vehideDry Weight : 
CE  -b :  HSUVModel:  :HSU 
CE  -bk:  HSUVModel:  :HSI 
CE  -c  :  HSUVModel:: HSU 
CB  -i :  HSUVModel:  :HSU\ 
CE  -I :  HSUVModel:  :HSU\ 
CB  -p  :  HSUVModel:: HSU 
Ports 

Operations 
Signal  Receptions 
Behaviors 

Template  Parameters 
Inner  Elements 
Relations 
Tags 

I 


HybridSUV 

ID  |  zi  (=1  j  ^  ^  Prc 

iper(ies:|  Expert  ▼  |  jX  Customize 

□  System  "" - " 

Name 

HybridSUV 

HSUVModel::  HybridSUV 

Owner 

CD  HSUVModel 

Is  Encapsulated 

r-  <undefined> 

Applied  Stereotype 

HI  System  [Class]  [SysML  Profile:: No 
«*  HyperlinkOwner  [Element]  [UML  S 

Base  Classifier 

Realized  Interface 

Visibility 

public 

Is  Leaf 

r  false 

Is  Active 

I-  false 

Is  Abstract 

r  false 

Active  Hyperlink 

0]  HSUVModel : :  HybridSUV ::  Figure .. . 

Image 

To  Do 

Qualified  Name 

A  name  which  allows  the  NamedElement  to  be  identified  within  a  hierarchy  of 
nested  Namespaces.  It  is  constructed  from  the  names  of  the  containing 
namespaces  starting  at  the  root  of  the  hierarchy  and  ending  with  the  name 
of  the  NamedElement  itself. 

forward  | 


Filters  to 

add/remove  detail 


Built-in 

documentation 
on  each  model 
attribute 
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Model  vs.  Diagrams 


Reality 

-  Envisioned  or  actual 


Model 

-  Computer-oriented 

-  Master  repository 

-  Complete  for  intended  scope 


I  / 


Diagrams 

Human-oriented 
-  Subset  views 


Tools 

-Authoring,  viewing,  executing, ... 


AcknowliBgdlnts:  Selected  portions  from  Friedenthal  et  al.  2008  and  MagicDraw  samples. 

mtnmm 


[Part  2]  SysML  Concepts:  Essential  Prerequisites 

(highlights  from  our  SysML  101  &  102  courses) 

•  SysML  context:  system  modeling  &  general  modeling 

•  Representative  SysML  authoring  tool  (MagicDraw) 

H  Blocks  and  instances  [Round  i] 

■=>  Blocks  and  equation-based  knowledge:  parametrics 

•  Other  concepts  covered  in  later  Parts  as  needed: 

-  Requirements  representation,  traceability,  verification,  ... 

-  Activities  (function-based  behavior) 

-  Automated  model-based  document  generation 

-  Collaborative  modeling  environments 

Georgia 

Tech 

_ [Part  2]  38| 
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Fuel_Tank  structure  viewl 

SysML  block  definition  diagram  (bdd)  w/  a  block  and  instances 


bdd  [Package]  Fueljank[  Fueljank  structure-  viewl  )  | 


«block» 

L\ 

Fuel  Tank 

This  is  a  block  with  three  value 

YSti&S 

properties. 

capacity  gal 
current_amount  gal 
currentjullness  Real 

A  block  defines  structure 
similar  to  a  template  or  a  blank 
form. 

ft310 :  Fuel  Tank 

N 

capacity="l0.2" 
current_amount  =  "1 0.2" 
currentjullness  =  "1.0"  ' 

-  __ 

These  are  two  instances  of  the 
above  block. 

Instances  typically  contain 
specific  numbers  for  each 

numeric  value  property. 

ft330  :  Fuel  Tank 

If  you  change  the  above  block 
structure,  these  instances  will 
also  change  accordingly. 

capacity  =  "5.5” 
current_amount  =  "0.0" 

currentjullness  =  ”0.0" 

5.5  gal 


Georgia 

Tech 


_ 


Fuel_Tank  structure  view2  and  view3 

SysML  bdd  and  par  depicting  block  equation  structure 


bdd  [Package]  Fuel_Tank  [  Fuel_Tank  structure  -  view2 


J 


«block» 

Fuel Tank 


values 
capacity  gal 
current_amount  gal 
currentjullness  Real 


This  is  the  same  block  as  in  viewl .  Now  we  are 
showing  it  also  has  one  constraint  property  (eqnl ). 
This  equation  was  still  present  in  the  model  but  simply 
shown  in  viewl . 

See  this  block's  main  parametric  diagram  (par)  to  see 
how  the  value  properties  are  related  by  eqnl . 


"N 


This  is  the  same  block  as  above.  It  is  simply  presented  differently. 
Now  its  constraint  property  is  shown  as  a  black  diamond  arrow. 


h 


«block» 

Fuel  Tank 

f 

-eqnl 

^constraint* 

RatioEqn 

values 
capacity  gal 
curremt_amount  gal 
currentjullness  Real 

constraints 
{fr  =  fcur  /fcap} 

parameters 
fr  Real 
fcap  gal 
fcur  gal 

This  is  a  constraint  block. 

Constraint  blocks  define 
reusable  equations  and 
associated  variables  (called 
constraint  parameters). 


capacity  =“10. 2“ 
current_amount  =  “1 0.2" 
current_fullness  =  "1 .0” 


These  are  the  same  two  instances  a: 


"N 


capacity  =  "5.5“ 
current_amount  =  "0.0" 
current_fullness  =  "0.0" 


par  [Block]  Fuel Tank  [  ||;  Fuel Tank  structure  -  view3  ]  | 


capacity 


current_amourit 


currentjullness 


e2  fcap 

eqnl :  RatioEqn 

j 

— 1  [fr  =  fcur /fcap] 

el  fcur 

3  n 

fr 

e3 

These  are  the  same  model  elements  seen  in  viewl  and  view2. 

This  parametric  diagram  depicts  other  facets  of  the  Fuel_Tank  block  -  in 
particular,  how  the  properties  are  constrained  by  equation  eqnl . 

ng  connectors  (named  el  -e3  here)  are  effectively  like  equality  relations. 

Some  SysML  parametric  solving  tools  (such  as  ParaMagic)  perform  automatic 
substitution  to  replace  each  constraint  property  name  with  the  name  of  its 
corresponding  connected  value  property. 

For  example,  before  substitution,  equation  eqnl  is  this  (as  seen  above): 
f  r  =  f  cur  / 1  cap 

After  automated  substitution,  equation  eqnl  becomes  this: 
capacity  =  current_amount  /  currentjullness 
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huei  I  ank  parametrics  execution 

ParaMagic  interoperating  w/  equation  solvers  such  as 
Mathematica 


bdd  [Package]  Fuel_Tank[  Fuel_Tank  structure  -  view2a 


jr 


«block» 

Fuel  Jank 

L-eqn1 

«constraint» 

RatioEqn 

capacity  gal 
current_amount  gal 
current  Jullness .  Real 

constraints 

(fr  =  fcur  /  fcap} 

parameter? 

Ifr  Real 

Ifcap :  gal 
fcur  gal 

capaW=  “5.5" 
current_amount  =  "0.0" 
current_fullness  =  "0.0" 


state  1.1  (after  solving) 


par  [Block]  Fuel_Tank  [  j®§|  Fuel_Tank  structure  -  view3a  ] 


current_amount 


current  Jullness 


e2  fcap 

eqnl :  RatioEqn 

—  (fr  =  fcur /fcap} 

n _ . 

J 

el  fcur 

J 

1  _ _ _ 

tr 

Before  substitution,  equation  eqnl  is  this  (as  seen  above): 
f  r  =  fcur  /  fcap 


After  automated  substitution,  equation  eqnl  becomes  tt 
capacity  =  current_amount  /  current  Jullness 


instance  ft330  state  1 .0  (before  solving) 


|  Type  |  Causality  |  Values  | 


§  ParaMagic(TM)  16.9  spl  -  ft330 


Name _ |  Qualified  Name_^ 

Fuel_Tank  4Jxtras::ft330:(ft330)  Fuel_Tank 

•GD  capacity  REAL  given 

•Q]  current_amount  REAL  given 

•GD  current  Jullness  REAL  target 


5.500 

0,000 

????? 


Given  my  current_amount, 
how  full  is  my  tank? 


Expand  |  Collapse  All  | 


Solve 


Reset 


|  j  Update  to  SysMl.  T| 


root  (Fuel  Jank) 

Name  |  Local  |One...|  Relation 

Active  | 

eqnl  |Y  |”  currentJullness=current_amount/capacity 

17 

instance  ft330  state  1.1  (after  solving) 


s  ParaMagic(TM)  16.9  spl  -  ft330 


^jnjxj 


Name 


Qualified  Name^ 

Fuel_Tank  4_Extras::ft330:(ft330) ' 

CD  capacity 
CD  current_amount 
•O]  current  Jullness 


Type  |  Causality  |  Values 


Fuel_Tank 
REAL  given 

REAL  given 

REAL  target 


5,500 

0.000 

0.000 


Expand  |  Collapse  All  |  Solve  |  Reset  | 


root  (Fuel  Jank) 

Name  |  Local  1 

One.., 

Relation 

|  Active  | 

eqnl  |y 

r 

current  Jullness=current amount/capacity 

1  P  | 

Fuel_Tank  parametrics  execution 

Changing  input/output  direction  (causality)  in  the  same  instance 


bdd  [Package]  Fuel  Jank  [  |j|j  FuelJ 


Jank  structure  -  view2a  ] 


«block» 

Fuel  Jank 

-eqnl 

«constraint» 

RatioEqn 

values 
capacity  gal 
current_amount  gal 
current  Jullness  Real 

constraints 

(fr  =  fcur /fcap} 

parameters 
'fr  Real 
fcap :  gal 
fcur  gal 

What  current_amount 
will  give  me  a  tank 
that  is  half  full? 


capacity  =  “5.5" 
current_amount  =  "2.75" 
current_fullness  =  "0.5" 


state  2.1  (after  solving) 


par  [Block]  Fuel  Jank  [  ®*jj  Fuel  Jank  structure  -  view3a  ] 


currentamount 


fcap  eqnl :  RatioEqn 

—  {fr  =  fcur /fcap} 


current  Jullness 


LL 


Before  substitution,  equation  eqnl  is  this  (as  seen  above): 
f  r  =  fcur  /  fcap 


After  automated  substitution,  equation  eqnl  becomes  this: 
capacity  =  current_amount  /  current  Jullness 


A 


instance  ft330  state  2.0  (after  changing  causalities,  and  before  solving) 

1 . . . .  ^ 


Qualified  Name 


Type 


Causality  Values 


|4_Extras:  :ft330:  :ft330  Fuel  Jank 
QD  capacity  REAL  given  5.500 

■Q]  current_amount  REAL  AtargeTA  ????? 

CD  current  Jullness  REAL  V  given  )  0.500 


Expand  |  Collapse  All  | 


Solve 


|  Reset  |  Update  to  SysML  | 


root  ( Fuel  Jank) 

Name  |  Local  I  Oneway  |  Relation 

Active  | 

eqnl  |Y  |currentJullness=current amount/capacity 

17 

instance  ft330  state  2.1  (after  solving) 

Qualified  Name  |  Type  |  Causality  |  Values^ 


4_Extras::ft330::ft330 


•CD  capacity 
•CD  current_amount 
•CD  current  Jullness 


Fuel  Jank 
REAL  given 

REAL  target 

REAL  given 

Reset  I  Update  tc 


5.500 

2.750 

0.500 


root  (Fuel  Jank) 

Name  | 

Local 

Oneway | 

Relation 

Active  | 

eqnl  1 

lY 

r  ' 

current  Jullness=current amount/capacity 

1  17 
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Enabling  Executable  SysML  Parametrics 

Commercialization  by  InterCAX  LLC  in  Georgia  Tech  VentureLab  incubator  program 


Advanced  technology  for  graph  management  and  solver  access  via  web  services. 


Tech 


Productionizing/Deploying  GIT  Xa/Too/s™ 

Technology  for  Executing  SysML  Parametrics 


www.lnterCAX.com 


Tool 

Vendor 

SysML  Authoring 
Tools 

Prototypes  by 

GIT 

Products  by 
InterCAX  LLC 

Atego 

Studio 

Yes 

ParaSolver™ 

(formerly  Artisan) 

c.2005 

1st  release:  2010-3Q 

EmbeddedPlus 

E+  SysML /RSA 

Yes 

c.2006 

— 

No  Magic 

MagicDraw 

Yes 

c.2007 

ParaMagic® 

1st  release:  2008-Jul-21 

Telelogic/IBM 

Rhapsody 

— 

Melody™ 

1st  release:  201 0-1 Q 

Sparx  Systems 

Enterprise  Architect 

— 

EA  Parametrics 
Coming  2011 

n/a 

XMI  import/export 

Yes 

c.2006 

<tbd> 

Others  <tbd> 

Others  <tbd> 

<tbd> 

<tbd> 

[1]  Full  disclosure:  InterCAX  LLC  is  a  spin-off  company  originally  created  to  commercialize  technology  from  RS  Peak’s  GIT  group.  GIT  has  licensed  technology  to  InterCAX  and  has  an 
GeOftgilnstake  inf  the  company.  RS  Peak  is  one  of  several  business  partners  in  InterCAX.  Commercialization  of  the  SysML/composable  object  aspects  has  been  fostered  by  the  GIT 
TtedJheLab  incubator  program  (www.venturelab.gatech.eduj  via  an  InterCAX  VentureLab  project  initiated  October  2007. 
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Georgia 

Tech 


lnt<  1 
Prc 

£U 

4— ' 

£ 

£ 

5 


^InterCAX 

Modeling  &  Simulation  Technology 

Products 

SysMUUPDM  Parametric  Solvers 

*  Execute  parametric  models  using 

-  ParaMagitf1  for  Magic  Draw 

-  Melody'1'  for  Rational  Rhapsody 

-  ParaSoiver™  for  Artisan  Studio 

-  Solve  a rH  |  beta}  for  Enterprise  Architect 

*  Use  Mathematics  or  OpenModelica,  {free)  as  a  core  solver 

*  Link  to  Excel  spreadsheets  and  perform  batch  trade  studies 

*  Link  to  existing  MATLAB/Simulink  and  Mathermatica  functions 

SysML/VPDM  Integrations 

■  Math  tools  {Mathematics ,  MATLAB.  Excel! 

*  M&S  toois  (Sitmulink  STK.  OpenModelica) 

*  CAD  tools  i NX,  STEP  MCAD/AP2Q3,  ECAD/AP210} 

■  CAE  tools  i.  AN  SYS.  ABACUS  | 

■  Plus  tailored  interfaces  iTeamcenter/PLM.  in-house  tools) 

Services 

*  SysML  training  -  onsite,  offsite,  and  web-based 

www  .intercax-com/'sysmlrtra  in  i  hg 

-  Consulting,  coaching,  and  support  for  SysML  £  MBSE 

-  Custom  application  development 

Application  Areas 

*  Aerospace,  automotive,  and  marine  systems  ■ m 

-  Defense  and  intelligence 

*  Supply  chains  and  logistics 

*  Energy  and  sustainability 

*  Finance  and  risk  management 

*  Urban  planning  and  infrastructure 

Contact  Us 

75  5U'  Street  NW,  Suite  213,  Atlanta  GA  30318.  USA 
info@intercax.oom  *  +1-404-592-6897  *  [J  twitter.  com/InterC AX 


Report  No.  SERC-201 1-TR-018 


UNCLASSIFIED 


94 


23 


[Part  2]  SysML  Concepts:  Essential  Prerequisites 

(highlights  from  our  SysML  101  &  102  courses) 

•  SysML  context:  system  modeling  &  general  modeling 

•  Representative  SysML  authoring  tool  (MagicDraw) 

H  Blocks  and  instances  [Round  2] 

4  Blocks  and  equation-based  knowledge:  parametrics 

•  Other  concepts  covered  in  later  Parts  as  needed: 

-  Requirements  representation,  traceability,  verification,  ... 

-  Activities  (function-based  behavior) 

-  Automated  model-based  document  generation 

-  Collaborative  modeling  environments 


Exercise  0:  Automobile  Fuel  Capacity 

Stage  1  Model  (pl/3) 


Block  definition  diagram  Parametrics  diagram 


Georgia 

Tech 
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Exercise  0:  Automobile  Fuel  Capacity 

Stage  1  Model  (p2/3) 


Example  Instances 

Model  DNA  Signature  (after  solving) 


Tech 


_ 


Exercise  0:  Automobile  Fuel  Capacity 

Stage  1  Model  (p3/3) 


bdd  [Package]  vehicle4340[  gjj  vehicle4340  ] 
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[Part  2]  SysML  Concepts:  Essential  Prerequisites 

(highlights  from  our  SysML  101  &  102  courses) 

•  SysML  context:  system  modeling  &  general  modeling 

•  Representative  SysML  authoring  tool  (MagicDraw) 

4  Blocks  and  instances  [Round 3  -  main  building  block  patterns] 
4  Blocks  and  equation-based  knowledge:  parametrics 

•  Other  concepts  covered  in  later  Parts  as  needed: 

-  Requirements  representation,  traceability,  verification,  ... 

-  Activities  (function-based  behavior) 

-  Automated  model-based  document  generation 

-  Collaborative  modeling  environments 


Exercise  0:  Automobile  Fuel  Capacity  &  Mileage 

Stage  3  Model  (pl/3) 
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Exercise  0:  Automobile  Fuel  Capacity  &  Mileage 

Stage  3  Model  (p2/3) 


JT 


Example  Instances 
(after  solving) 


Model  DNA  Signature 


Exercise  0:  Automobile  Fuel  Capacity  &  Mileage 

Stage  3  Model  (p3/3) 


^  ParaMagic(TM)  16.9  spl 

vehicle4340 

Name 

Qualified  Name 

1  Type 

|  Causality 

|  Values  | 

r 

I  Vehicle 

p  Target  Model  Stage3::vehide4340::vehide4340 

Vehicle 

••••□G  current  Juel_amount 

REAL 

ancillary 

10.200 

j -O  current  Juel Jullness 

REAL 

ancillary 

0.650 

j-O  current  _remaining_miles 
j  ••••□]  distance_range 

state  1.1  (after  solving) 

REAL 

REAL 

ancillary 

target 

428.400 

659.400 

|™-Q1  fuel_capacity 

REAL 

target 

15.700 

hd  fuel_mileage 

REAL 

given 

42.000 

Ed  tankl 

[■■■O  capacity 
f  ■O  current_amount 
lO  currentjullness 
E-O  tank2 

1-0  capacity 
f-O  current_amount 
L-0  currentjullness 

Expand  Collapse  A 


3_Target_Model_Stage3:  :vehide4340:  :ft310 


3_Target_Model_Stage3:  :vehide4340:  :ft330 


Fuel_Tank 

REAL 

REAL 

REAL 

Fueljank 

REAL 

REAL 

REAL 


given 

given 

ancillary 

given 

given 

ancillary 


10.200 

10.200 

1.000 

5.500 

0.000 

0.000 


Solve  |  Reset  |  Update  to  SysML  | 


root  ( Vehicle ) 

Name 

Local 

Oneway  | 

Relation 

Active 

eqnla 

Y 

r  J 

f  uel_capacity =tankl .  capacity +tank2 .  capacity 

W 

eqnlb 

Y 

r 

current  Juel_amount=tankl .  current_amount+tank2 .  current_amount 

W 

eqn2a 

Y 

r 

distance_range=fuel_capacity*fuel_mileage 

W 

eqn2b 

Y 

r 

current_remaining_miles=currentJuel_amount*fuel_mileage 

17 

eqn3 

Y 

r 

current  Juel  Jullness=currentJuel_amount/fuel_capacity 

17 
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Broadly  Applicable  Technology 

Examples  of  Executable  SysML  Parametrics 


4 

-> 


Road  scanning  system  using  unmanned  aerial  vehicle  (UAVs 
UAV-based  missile  interceptor  system  trade  study 
Space  systems  (tutorials):  orbit  planning;  mass/cost  roll-ups 
Space  systems  (studies/pilots):  FireSat  (INCOSE  SSWG),  ... 

Space  systems  (actuals):  science  merit  function,  ... 

Environmentally-conscious  energy  systems  /  smart  grid 
Manufacturing  “green-ness”  /  sustainability  assessments 
Electronics  recycling  network 

Regional  water  management  systems  (e.g.  South  Florida) 

Next-Generation 

Mechanical  part  design  and  analysis  (FEA)  Spreadsheet  Technology++ 


Georgia 

Tech 


(object-oriented,  multi-dimensional,  ...) 

Wind  turbine  supply  chain  management 
Insurance  claims  processing  and  website  capacity  model 
Financial  model  for  small  businesses 
Banking  service  levels  model 


JBL 


Model  “DNA  Signatures”  Using  SysML  Parametrics 


Panorama  Tool  by  Modeling  &  Simulation  Lab  (www.msl.gatech.edu) 
Examples  as  of  -9/2009  —  Low/Medium  Complexity 


a.  Snowman 


b.  Mini  Snowman 


c.  Snowflake 


d.  Mouse 


f 

NJ 

>vy- 

4 

■  X  1  *£ 

Kym 

e.  Cactus 


g.  Robot 


Test:  Match  the  actual  model  titles  (below)  to  their  “DNA 
signatures”  with  imagined  titles  (left). 


1 .  South  Florida  water  mgt.  (hydrology)  model 

2.  2-spring  physics  model 

3.  3-year  company  financial  model 

4.  UAV  road  scanning  system  model 

5.  Car  gas  mileage  model 

6.  Airframe  mechanical  part  model 


7.  Design  verification  model 

(automated  test  for  two  Item  6.  designs) 


g.  Springy  Snowflakes 


[Part  2]  56| 
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Recent  Models:  -Medium  Complexity 


2010-10  Model  size  =  0(1 00s)  equations,  0(1000+)  variables 

mfg.  sustainability:  airframe  wing  electronics  recycling  network 


supply  chain  metrics 


“Tumbleweed” 


2010-12: 

-20k  variables 
-15k  equations 

WIP: 

100K,  1 M,  ... 

Georgia 

Tech 


IPart  21  571 


Snowflake  Composition 

Five  composition  levels:  primitive  equation  to  system-of-systems 


»  a,  »  H  * 


•  *  « 


Snowflake  de  Spring 


[Part  2]  58| 
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Using  SysML  to  Evaluate  Sustainability  Metrics 

(similar  to  Other  Metrics:  Design  Flexibility,  ...) 

F-86  wing  section  test  case 


Aluminum  Cast  and  Machined  Components 
More  Room  for  Internal  Parts 
Fewer  Manufacturing  Operations 
Heavier 


Georgia 

Tecti 


Rolled,  Bent,  Stamped  Sheet  Metal 
Less  Room  for  Internal  Parts 
More  Manufacturing  Operations 
Lighter 

Source:  Bras,  Romaniw,  etal.  10/2009 
www.sdm.gatech.edu 
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F-86  Wing  Section  Test  Case  in  SysML  Parametrics 

Comparing  Sustainability  Metrics  for  Design  Alternatives 


S  ParaMagic(TM)  16.5  -  Instance  Library 


Symbol 


Type 


Causality  Values 


UnitPart  ,  UnitPart 

•  forming  OriGHt®^  ListOfDieCastingOps 

-•  materialRemoval  ListOfMaterialRem... 

•  sawing  .  ListOfSawingOps 

^  unitPartCarbonDioxide  |\y|ultl'^  +  ”  REAL 

-•  unitPartCarbonDioxidelnvestment  _  gQSn^*^  REAL 

unitPartEnergy  bP'  REAL 

-•  unitPartEnergylnvestment  REAL 

unitPartFinalMass  REAL 

-•  unitPartOperationCarbonDioxide  REAL 

•  unitPartOperationEnergy  REAL 

REAL 


target 

ancillary 

target 

ancillary 

target 

ancillary 

ancillary 


34.825971386499 

34.821506 

196.777.522.3729., 
194,940,000 
1.756994 
0.004465386499 

1.837.522.372948.. 
1 1.033006 


|  Expand  ||  Collapse  All  | 


Reset  I  Update  to  SysML 


Value 

Description 

Change  Aluminum  to 
Steel 

Total  Carbon 

Total  003  for  Life  of  Part  (up 

DfOKidC 

to  this  stage) _ 

Total  Energy  for  Life  of  Part 

■25.3  kg 

Total  Energy 

|up  SO  this  Stage)  _ _ 

:  10s. 4  M)  =  -ZS.EtWh 

Lniwitod  Carbon 

jcoi  m  Harvest  Ing/fltfming 

ppxicjE 

flaw  Materials 

-153  kg 

invested  Energy 

Energy  In 

Harvesting^Refining  Raw 
Material* _ 

410.4  MJ  ^  30.7  kWh 

Opaodon  Carbon  [Monufocturin^/Fabruotion 
IfHoxktc  £02 

*0.02  ka 

Manufacitifinq  /F  a  t>  r  tc  o  f jo  r> 
operatia  rt  Efltfrjy  *  rterpy 

+502.2  k.i  -  +1.4  MV" 

Tjnjl  Mass 

final  Part  Maw 

*3.4  kR 

Waste  Mass 

Total  Manufacturing  Waste 
Mass 

+04  kg 

Source:  Bras,  Romaniw,  etal.  10/2009 
www. sdm.gatech.edu 


Recent  Models:  -Medium  Complexity 

F-86  Cast  Wing  Section  [adapted  from  Bras,  Romaniw,  et  al.]  -  pl/3 


SysML  parametrics  stats 
===  structural  stats 
23  blocks 

218  value  properties 

38  part  properties 

0  reference  properties 

0  shared  properties 

12  complex  aggregate  properties 

0  primitive  properties 

195  constraint  properties  -  regular 

0  constraint  properties  -  xfwExternal 

0  constraint  properties  -  cMathematica 

===  instance  stats 

184  block  instances 

1879  value  property  slots 

165  part  property  slots 

0  reference  property  slots 

0  shared  property  slots 

53  complex  aggregate  members 

0  primitive  aggregate  members 

346  constraint  property  eqns  -  regular 

0  constraint  property  eqns  -  xfwExternal 

0  constraint  property  eqns  -  cMathematica 


cast  wing  -  total  assembly 
(JoinNosesToSpar  highlighted) 
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Regional  Water  Mgt.  System:  Hydrology  Model 


Model  DNA  signature  (flattened  graph  “panorama”  view) 
(auto-generated  from  SysML 


Georgia 

Tech 
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Supply  Chain  Model 

for  Global  Supply  Chain  Management  &  Optimization 


«block» 

System 


Sources:  Dirk.Zwemer@lnterCAX.com  and  Georgia  Tech 


-Cust  1 


«block» 

Customer 


-Cmpyw 


«block» 

Company 


-Prodn  1 


«block» 

ProductionSite 


«block» 

SitePartDemand 


-SPrSjl 


-BoMjl 


«block» 

SiteProductDemand 

ISPr 

)  «block» 

>SiteProductSupply 

-MB1 

«block» 

Model_BoM 

- - 1 

SPrD-f 

l.4 

■ - v- 

-SPtSlJl. 


«block» 

SitePartSupply 


-Partjl 


«block» 

SKU 


-  Generic  (shown) 

-  Wind  turbine-specifics  (not  shown) 


-whJi.* 

«block» 

Warehouse 


-WHPartp..* 

«block» 

WarehousePart 


-SupPartl.* 

«block» 

SupplierPart 


Supply  Chain  Model  -  SysML  Parametrics 

Connect  to  Optimization  Models,  Compute  Value-at-Risk 


Ex.  Given  100’s  of  product  orders  and  sourcing  plans  for  the  next  12  months,  what  percent 
of  my  business  is  at-risk  if  Supplier  X  does  not  deliver,  or  if  Part  Y  becomes  obsolete? 


jw]:  USD(OOO) 


«constraint» 

DS1  :  DollarSum 

{high  =  sum(low)} 


_  ProjTransCost :  USD(OOO) 


{high  =  sum(low)} 

high:USqpjO)- 


ProjPartsCost :  USD(OOO) 


«constraint»  ,  .  .  j 
US9  :  UnitSum  h'gh  :  Rea* 

'  Zl  low  :  Real  [1  ..*]  {high  =  sum(low)}| 


G  :  Real 


-  ProjValue  :  USD(OOO) 


-  ProjVAR  :  USD(OOO) 
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[Part  2]  SysML  Concepts:  Essential  Prerequisites 

(highlights  from  our  SysML  101  &  102  courses) 

•  SysML  context:  system  modeling  &  general  modeling 

•  Representative  SysML  authoring  tool  (MagicDraw) 

•  Blocks  and  instances 

•  Blocks  and  equation-based  knowledge:  parametrics 
4  Other  concepts  covered  in  later  Parts  as  needed: 

-  Requirements  representation,  traceability,  verification,  ... 

-  Activities  (function-based  behavior) 

-  Automated  model-based  document  generation 

-  Collaborative  modeling  environments 

-  Healthy,  viable,  growing  technology  ecosystem 
(many  SysML  users,  tools,  support,  ...) 

Georgia 

Tech 

_ Part  21  69l 
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OMG  SysML  1.0  Participants 


Spec  Released  Sept  2007 


•  Industry  &  Government 

-American  Systems,  BAE  SYSTEMS,  Boeing,  Deere  &  Co, 
EADS-Astrium,  Eurostep,  Lockheed  Martin,  Motorola,  NIST, 
Northrop  Grumman,  oose.de,  Raytheon,  THALES 

•  Vendors 

-Artisan,  EmbeddedPlus,  Gentleware,  IBM,  l-Logix,  Mentor 
Graphics,  No  Magic,  PivotPoint  Technology,  Sparx  Systems, 
Telelogic,  Vitech  Corp 

•  Academia 

-  Georgia  Institute  of  Technology 

•  Liaison  Organizations 

-  INCOSE,  ISO  10303  AP233  Working  Group 


Georgia 

Tech 


SysML  Technology  Status  &  Viability 


Official  Site:  www.omqsvsml.org  ( Beware  of  imitations!) 


•  Spec  vl  .0:2007-09  vl.  1:2008-11  vl. 2:  2010-06  v1.3:WIP 


v2.x:  RFI  preparation  workshop  -  2008-12 

http://www.omq.org/spec/SvsML/ 


Strong  vendor  support 
Good  learning  infrastructure 
-  Books,  short  courses,  academic  courses, 


-  http://www.omq.org/ocsmp/ 

Expanding  production  usage 


-  INCOSE  MBSE  Initiative  workshops:  2007-201 1 

-  http://www.pslm.qatech.edu/events/frontiers/:  2006,  2007,  2008.  2011 

-  OMG  SysML  Info  Days:  2008-12;  IC-MBSE  2008,  2009,  2010 

GeSrgiJOverall  Status:  Healthy  and  Growing  © 
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OMG  Certified  Systems  Modeling  Professional 

Certification  Program  Overview 


The  OCSMP™  Certification  Program  is  currently  entering  the  early  stages  of  development.  The  program  is  will  award  four  levels  of 
certification,  arranged  in  a  single  hierarchy,  and  corresponding  multiple-choice  examinations.  Our  committee  of  SysML  domain 
experts  will  define  program  details  including  the  exact  array  of  exams,  their  levels,  names  and  topical  coverage. 

When  the  domain  experts  have  defined  the  coverage  limits,  OMG  will  assemble  a  larger  group  of  experts  to  write  the  exam 
questions  and  multiple-choice  answers,  which  will  be  subject  to  psychometric  verification  before  being  published  world-wide  by 
our  test  delivery  company,  Pearson  VUE,  in  their  worldwide  network  of  testing  centers. 


The  Exams 


The  program  will  award  the  OMG  Certified  Systems  Modeling 
Professional  certification  at  four  levels.  The  first  level,  OCSMP 
Model  User,  covers  a  wide  range  of  essential  MBSE  and  SysML 
knowledge  and  skills  and  so  enhances  the  resume  of  those  who 
contribute  to  a  model-based  systems  engineering  project.  Building 
on  this  foundation,  since  all  lower  levels  will  be  prerequisites  for 
the  levels  above,  are  three  levels  targeted  at  model  builders  and 
advanced  model  users. 

These  levels,  termed  OCSMP  Model  Builder  -  Fundamental, 
Intermediate,  and  Advanced,  cover  advanced  topics  with  an 
emphasis  on  the  interconnectedness  among  the  different  model 
viewpoints  that  gives  MBSE  its  advantage  over  conventional 
engineering  methods. 


OCSMP  Model  Builder  -  Advanced 


OCSMP  Model  Builder  -  Intermediate 


OCSMP  Model  Builder  -  Fundamental 


OCSMP  Model  User 


www.omg.org/ocsmp 


Status  as  of  Feb  2011 

-  Beta  testing  was  completed  for  all 
Levels  1-4  as  of  Dec  2010. 

-  Regular  exams  are  now  available 
for  all  Levels  1-4. 


OCSMP  Program 

If  you’re  a  Systems  Engineer,  an  OCSMP  Certification  at  a  suitable  level  represents  a  significant  credential  that  differentiates  you 
from  your  peers.  Your  superiors  will  think  of  you  when  they  assign  responsibility  for  projects  based  on  MBSE,  and  when  they  make 
decisions  on  promotion  or  compensation.  If  you’re  making  a  hiring  decision,  or  awarding  a  promotion  or  a  raise,  you  know  that  the 
OCSMP  Certified  candidate  stands  out  -  he  or  she  has  studied  the  material  and  practiced  the  skills  required  for  his  level,  and  will 
bring  the  benefits  of  MBSE  to  the  projects  that  they  work  on.  And,  if  your  company  sells  engineering  services  to  clients  on  contract, 
your  certified  staff  sets  you  apart. 


OMG  certification  examinations  -  for  OCSMP  for  System  Modelers,  and  our  programs  OCEB™  for 
BPM,  OCUP™  for  UML,  and  OCRES™  for  Real-time  and  Embedded  -  are  administered  by  Pearson 
VUE  at  their  world-wide  network  of  secure  testing  centers. 

Gee 


PEARSON 

\M£ 


_ 


OMG  Certified  Systems  Modeling  Professional 

OCSMP  Model  User  (Level  1)  Coverage  Table  (pl/2) 


Models  of  Requirements: 


Interpreting  Requirements  on  Requirement  Diagrams 

Concept  of' "requirement";  key  relationships  including  derive,  verify,  satisfy,  refine,  trace,  containment; 
Requirement  Diagram  description,  purpose,  and  benefits; 


Geo/gwr 


Interpreting  System  Functionality  on  Use  Case  Diagrams 

Use  Case  Diagram  description,  purpose,  and  benefits;  use  case  structure  encompassing  use  case, 
actor,  and  subject;  basic  relationships  including  association,  include,  extend,  and  generalization. 

Models  of  System  Structure: 

Interpreting  Model  Organization  on  Package  Diagrams 

Package  Diagram  description,  purpose,  and  benefits,  aspects  of  packages  including  ownership  of 
elements,  and  defining  a  namespace;  relationships  including  containment  and  dependency; 
concepts  of  view  and  viewpoint. 

Interpreting  Sy  stem  Structure  on  Block  Diagrams 

Block  definition  and  description,  including  definition  vs.  usage;  valuetype  [with  units),  block  features 
including  value  properties,  parts,  references,  and  operations.  Block  Definition  Diagram  description, 
purpose,  and  benefits;  compartments;  relationships  between  blocks  including  specialization  and 
associations ;  multiplicities . 

Internal  Block  Diagram  description,  purpose,  and  benefits:  enclosing  block;  flow  ports  and  standard 
ports;  connectors  and  item  flows;  representation  of  parts. 

Interpreting  System  Constraints  on  Block  Definition  Diagrams  and  Parametric  Diagrams 
Interpreting  constraint  blocks  on  Block  Definition  Diagrams;  Parametric  Diagram  description, 
purpose,  and  benefits;  constraint  properties,  constraint  parameters,  and  constraint  expressions; 
connecting  constraint  properties  and  value  properties  with  binding  connectors. 


7% 


7% 
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OMG  Certified  Systems  Modeling  Professional 

OCSMP  Model  User  (Level  1)  Coverage  Table  (p2/2) 


Models  of  System  Behavior: 


Interpreting  Flow-Based  Behavior  on  Activity  Diagrams 

Activity  Diagram  description,  purpose,  and  benefits;  I/O  flow  including  objectflow,  parameters  and 
parameter  nodes,  and  pins;  control  flow  including  control  nodes;  activity  partitions  (swimlanes);  and  1 3% 

actions  including  decomposition  of  activities  using  call  behavior  action;  send  signal  action;  and 
accept  event  action 

Interpreting  Message-Based  Behavior  on  Sequence  Diagrams 

Sequence  Diagram  description,  purpose,  and  benefits;  lifelines;  asynchronous  and  synchronous  7% 

messages;  interaction  references  [to  elements  outside  the  diagram}. 

Interpreting  Event-Based  Behavior  on  State  Machine  Diagrams 

State  Machine  Diagram  description,  purpose,  and  benefits;  states  and  regions  including  state. 
regions,  initial  state  and  final  state;  transitions  including  trigger  by  time  and  signal  events,  guard,  and 
action {i  e  effect);  and  behaviors  including  entry,  exit,  and  do. 

Cross-Cutting  Constructs; 

Interpreting  Allocations  Across  Multiple  Diagram  Types;  Other  Topics 

Allocation  description,  purpose  and  usage;  AllocatedFrom  and  AllocatedTo;  representation  including 
callouts,  compartments,  allocate  activity  partitions,  and  tables;  special  notations  for  comment,  20% 

rationale,  problem,  and  constraint.  Some  concepts  relating  to  diagrams:  diagram  frames,  ports, 
parameters,  and  anchors  on  diagram  frames;  diagram  header,  and  diagram  description.  Stereotype. 


Georgia 

Tech 


OMG  Certified  Systems  Modeling  Professional 

OCSMP  Authors 


JD  Baker 

^Lrhc  MathWorks 

Alan  Moore 

1 

No  Magic 

The  MathWorks 

% 

^  InterOVXux 

Manas  Bajaj 

Georgia 

Russell  Peak 

InterCAX 

Tech 

Georgia  Institute  of  Technology 

IBM. 

Graham  Bleakley 

IBM 

Jon  Siegel 

OMG 

Roger  Burkhart 

l(ir  CEPHAS 

Ernest  Stambouly 

John  Deere 

yw,  CONSUL  UNO 

Cephas  Consulting  Corp 

. rr^ 

Sanford  Friedenthal 

Lockheed  Martin 

Raytheon 

Rick  Steiner 

Raytheon 

visumpoint 

Robert  Larlo 

oose. 

Tim  Weilkiens 

Visumpoint 

innovative  IntornoWc 

oose 

Sam  Mancarella 

dPL 

Joe  Wolfrom 

srjn  ms 

Sparx  Systems 

Johns  Hopkins  APL 

G U uhtjj^www.oma.ora/ocsmD/authors.htm  (2010-10-1 2) 

Tech 
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Examples  of  SysML  in  Production  Usage 


•  OMG  SysML  Info  Days  -  2008-12* 

-  Application  of  SysML  to  a  Navy  Shipboard  Combat  System 
by  J.  Watson  (Dec  10,  2008),  and  others 

•  SysML  RFI  Survey  -  2009 

-  Results  summary  by  R.  Cloutier  at  2009-12  OMG  mtg  in  Long  Beach 
(OMG  document  syseng-09-12-04  —  http://svsenq.omq.org/) 

-  SysML  2009  Request  for  Information  (RFI)  Response  Summary.  Bone  M  and 
Cloutier  R,  8th  Conference  on  Systems  Engineering  Research  (Mar  2010).  * 

•  INCOSE  MBSE  Initiative 

-  Wiki  with  examples:  http://www.omgwiki.org/MBSE/ 

•  See  Telescope  team  page  for  full  MagicDraw  model 

-  INSIGHT  Special  Issue  2009-12*  www.incose.org 

•  Plus  others  emerging  at  an  increasing  pace 

Seorgia 

TectL  See  www.omqsvsml.org  for  links  to  asterisked(*)  items  and  others.  __ 


Model-Based  Systems  Engineering  in  Industry 


Actively  used  in  most  large  companies  in 
Aerospace,  Defense,  Autom§#^:  23% 

-  In  a  recent  SysML  surveypefense:  20% 

45  companies  participatedstomotive:  7% 

Other:  30% 

No  longer  small  pilot  studies! 


Project  Duration 

1  mo  -  1  year:  20% 
1  year  -  3  years:  35% 
>  3  years:  45% 


Project  Size 

<10  people:  28% 

10-100:  40% 

100-  1000:  22% 

>  1000  people:  10% 


■  MBSE  is  becoming  part  of  day-to-day 
engineering  practice 

e™gjPata  Source:  Robert  Cloutier  —  http://www.omg.org/cgi-bin/doc7syseng/2009-12-04) 
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MBSE  in  Industry  &  Government 

Selected  Publications  from  IC-MBSE  2010 


IC-MBSE  2010  -  3rd  International  Conference  on  Model-Based  Systems  Engineering 

September  27-28,  2010.  George  Mason  University,  Fairfax,  Virginia,  http://seor.gmu.edu/mbse2010/ 

•  Complex  Product  Family  Modeling  for  Submarine  Combat  System 
Steven  Mitchell  (Lockheed  Martin) 

•  Bridging  the  Gap:  Modeling  Federated  Combat  Systems 

Danielle  Robinson,  Brandon  Gibson,  Steven  Mitchell  (Lockheed  Martin  MS2) 

•  End  to  End  Maritime  Surveillance  Architecting  using  Model  Driven  Engineering 
Thomas  Wheeler,  Sara  Orr,  William  Wong  (MITRE) 

•  DoDAF  System  Architecture  Linkages  to  Modeling  and  Simulation 
Matthew  Carmona,  Sean  McGervey  (Northrop  Grumman  Electronic  Systems) 

•  Improving  the  Design  Quality  of  Complex  Networked  Systems  Using  a  Model-Based  Approach 
Stephan  Marwedel,  Nils  Fischer  (Airbus  Deutschland),  Horst  Salzwedel  (Mission  Level  Design  GmbH) 

•  We  can  Change  the  Culture  of  Systems  Engineering  with  MBSE! 

Robert  Healy  (Raytheon) 

•  MBSE  Process  Using  SysML  for  Architecture  Design,  Simulation,  and  Visualization 
Gundars  Osvalds  (Northrop  Grumman) 

•  Developing  a  Strategy  and  Roadmap  for  Advancing  the  State-of-the-Practice  of  MBSE  within  Your 
Organization  -  Jeff  Estefan  (NASA  Jet  Propulsion  Laboratory) 

•  Model-based  Systems  Engineering  (MBSE)  Using  SysML 
Sanford  Friedenthal  (Lockheed  Martin) 

•  Models  as  a  Foundation  for  Systems  Engineering  -  Should  We  Expect  a  Breakthrough? 

GeorgfcPavid  Long  (Vitech  Corp.) 

Tteclr  suaiSJj? 


MBSE  in  Industry  &  Government  I 

Other  Selected  Publications,  Trends,  Anecdotes,  Etc. 


•  Navy  CANES  project  [http://www.public.navy.mil/spawar/Press/Documents/Publications/3.4.10_CANES.pdfetc.] 

-  SysML  model  used  in  generating  RFP 

-  SysML  model  required  as  a  deliverable 

•  NASA  JPL  study:  Piloting  Model  Based  Engineering  Techniques  for  Spacecraft 
Concepts.  Bjorn  Cole,  Chris  Delp,  Kenny  Donahue,  INCOSE  IS  2010,  Chicago. 

-  Received  INCOSE  Best  Paper  Award.  Available  at  www.omgsysml.org 

•  Agile  Systems  Development  -  Bruce  Douglass  (IBM  Rational) 

-  PLM  Road  Map  2010,  CPDA,  Plymouth  Ml. 

•  Emerging  Anecdotes  ... 

-  Practically  all  DoD  1st  tier  and  many  2nd  tier  contractors 
have  some  type  of  MBSE  effort  underway 

•  Ranging  from  grassroots  interest  groups  to  major  internal  initiatives 

•  Similar  to  adoption  of  CAD/CAM/CAE  (~’70s/’80s  to  present) 

-  Other  US  gov  usage:  NASA,  DOE  (Sandia),  ... 

-  Growing  demand  for  courses  and  consulting 

-  Example  business  impact:  A  DoD  contractor  (who  had  SysML  model)  won  a  program 
over  another  contractor  (no  SysML  model).  Feedback  was  that  their  SysML  model  gave 
DoD  more  confidence  their  proposal  would  work  ... 

Georgia 

Tech 
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Presentation  Contents 

SERC  RT21  -  GIT  SysML-based  Approach 

•  [Part  1]  Intro  &  context 

•  [Part  2]  SysML  concepts:  essential  prerequisites 

4*  [Part  3]  Walk-through  of  concepts  &  examples/demos 
-Includes  SysML-based  V&V  building  blocks 

•  [Part  4]  Summary  &  Recommendations 


Georgia 

SYSTEMS  I-: NCi  1 M Eli K 1  Ml 

Tech 

n  u  d  u  cj  r  u  H  Corn  ul 

Part  31  83 

[Part  3]  Contents 

•  Core  embedded  V&V  concepts  [ct-i  tod-5] 

•  Higher-level  concepts  -  round  1  [CT-6toCT-ii] 

-  Sample  SysML-based  V&V  building  blocks 

-  Example  applications 

•  Higher-level  concepts  -  round2  [CT-i2toCT-i5] 

-  Verifying  external  models  &  systems  via  SysML 

•  Higher-level  concepts  -  round3  [CT-i6toCT-i7] 

-  MIM  architecture  for  M&S  patterns 

-  Other  concept  extensions 


Georgia 

Tech 
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CT-1:  Automated  units  consistency  checking 


consistent  value  types 


«  j  «*  fjnli: 


fqnh :  MikiCc 


D-Q 


UX.L  ^ 

'  I  |n  ■  mj  .1 1  MS  I 

■  -  _ 


"  . . 


. —  1“ 

«<■  h-*l  j 


:r. 


... 


inconsistent  value  types 


D Q 


I  | 

I  -Ifr-tef  Jfp») 

f^-b  J".„ 


tl««*  1"*l 


i.rMH^WiaT|  ' 


-I 


I  *{>•»*  0  *  F  •  -|«1  £  *  -  n  0 

Filter:  |  ". 

Element  |  Severity  |,.,| 

Message  |...| 

■/-  Binding Connector:elO[3_Target_Model_Stage3::Vehicle::current_fuel_amount...  A  warning  ... 

Binding  Connector :el l[3_Target_Model_Stage3: : Vehicle : :fuel_mileage  -  3_Tar...  ^  warning  ... 

The  two  ends  of  a  binding  connector  must  have  either  the  same  type  or 
types  that  are  compatible  so  that  equality  of  their  values  can  be  defined. 

The  two  ends  of  a  binding  connector  must  have  either  the  same  type  or 
types  that  are  compatible  so  that  equality  of  their  values  can  be  defined. 

CT-1-1 


CT-2:  Automated  equation  checking 


valid  constraint  expression 


par  [Block]  Vehicle!  |g§]  Vehicle 


JT 


eqn2b :  MilesEqn 

—  {miles  =  fuel ‘mileage) 

B  g 


invalid  constraint  expression 


par  [Block]  Vehicle!  H  Vehicle  ] 


™el  — |  eqn2b  :  MilesEqn 

mileage  ==j  {miles  =  myfuel  *  mileage  aal } 


_  remaining_m 


o 


JrtM  t*A*.  Jiij.l.lj?  fc  |tf  jjM 


E*I  I1  >>  if 


™aw 


Parsing  Failed,  expression:  miles  =  myfuel  *  mileage  aal  has  syntax 
errors  caused  by  aal  and  myfuel. 


CT-2-1 
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CT-3.1:  Model  integrity  checking 

instance  consistency  with  element  definitions 


element  definitions 


«block» 

Vehicle 

tankl 

«block» 

Fuel Tanh 

tank2 

values 

values 

distance  _range :  mi 

capacity  gal 

fuel_capacity  gal 

fuel_mileage  mpg 

valid  instance  invalid  instance:  tankl  should  have  only  one  value 


Georgia 

Tech 

CT-3-ll 


CT-3.2:  Propagating  model  updates 

Renaming  an  element  auto-updates  all  occurrences  throughout  the  model 


original  model  -  bdd  view  updated  model  -  bdd  view 


Georgia 

T«h 


updated  model  -  other  views  (auto-updated) 
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CT-4:  Augmented  language-level  integrity: 
ensuring  best  practices,  etc. 


recommended  practice  for  property  names:  having  no  spaces 


par  [Block]  Vehicle!  ||  Vehicle  jl 

fuel 

eqn2b :  MilesEqn 

el  1 : .  mileage 

{miles  =  fuel  *  mileage} 

D  <=' 

non-recommended  practice  for  property  names:  having  spaces 


par  [Block]  Vehicle!  B  Vehicle  ] 


IT 


fuel  —  eqn2b  :  MilesEqn 

mileages  {miles  =  fuel  *  mileage} 


-□ 


© 


XJ 


If  if 


Georgia 

Tech 


Property  name  “remaining  miles”  contains  one  or  more 
non-recommended  character(s). 


CT-4-1 


[Part  3]  Contents 

•  Core  embedded  V&V  concepts  [ct-i  tod-5] 
Higher-level  concepts  -  roundl  [CT-6toCT-ii] 

-  Sample  SysML-based  V&V  building  blocks 

-  Example  applications 

•  Higher-level  concepts  -  round2  [CT-i2tod-i5] 

-  Verifying  external  models  &  systems  via  SysML 

•  Higher-level  concepts  -  round3  [CT-i6toCT-i7] 

-  MIM  architecture  for  M&S  patterns 

-  Other  concept  extensions 


Georgia 
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CT-6.1:  Margin  Concepts 

margin  of  safety,  factor  of  safety,  etc. 


•  Common  concept  used  in  aerospace 
industry,  etc.,  for  quantifying  requirements 
&  objectives  (e.g.,  in  stress  analysis) 

•  Analogous  to  fundamental  elements  in 
electrical  circuits  (resistors,  diodes,  ...) 

•  Useful  for  non-physics  contexts,  too 
(e.g.,  target  cash-on-hand  in  a  business) 

•  Suggested  next  steps:  Create  reusable 
SysML  libraries  of  such  concepts  to  kick- 
start  broader  usage  for  V&V. 

•  Other  variations:  max  vs.  min  allowables, 
ranges,  tolerances,  multiple  levels  of 
acceptability  (not  just  pass/fail),  expect 
delta  trend  vs.  baseline  ... 


CT-6-1 


CT-6.2:  Comparator  Concepts 

Automated  checks  on  deltas  (a  vs.  b)  and  expected  equalities 


bdd  [Block]  Comparator  [  ij|j  Comparator  ]j 


^blocks- 

Comparator 


rl  ;  Delta_ab_Eqn 
r2 ;  ComparisonWrt_a_Eqn 
r3 ;  ComparisonVW_b_Eqn 
r4 :  Equality _Test 


a  Real 
b  Real 

comparisonWrt_a  Real 
comparisonWrtJj  Real 
delta_ab  Real 
equalrty_flag :  Real 


•  Similar  concept  and  intent  as 
Margin_Block,  except  this  is 
used  mostly  for  automated 
verification  of  expected  values 
(e.g.,  to  verify  M&S) 

•  Libraries  of  comparator 
variations  (similar  to  previous 
slide  variations)  are  also 
proposed,  including  checking 
equalities  for  other  types  of 
object  such  as  strings  (diff). 

CT-6-2 
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CT-7.1:  Automated  requirements  verification 

Example:  SimpleSat  Parametrics  Tutorial  (slide  1  of  4) 


bdd  [Package]  SimpleSat  [  JJjL!  SimpleSat  ]  | 


values 

mass :  kg{unit  =  Kilogram} 

constraints 

rl  :  MassBalance 


-reqVerifierMass 


r 

T 

+propulsionSubSys  j+instruments 

+controllerSubSys|  +powerSubSys 

PropulsionSystem 

Instruments 

ControlSystem 

Power  System 

power :  W{unif=  Watt} 
mass :  kg{unit  =  Kilogram} 

values 

power :  W{unit  =  Watt} 
mass :  kg{unit  =  Kilogram} 

values 

power  :W{unit  =  Watt} 
powerRating :  W{unit  =  Watt} 
mass  :  kg{unit  =  Kilogram} 

values 

power  :W{unit=  Watt} 
mass :  kg{unit  =  Kilogram} 

-reqVerifierPower 

T-reqVerifierRating 


ModelOverview  -  Exercise  1 


margin  =  (alw-det)  /  det 
l.e.,  margin  >=  0  means  it  passes. 


ModelOverview  -  Exercises  2  and  3  SimpleSat  -  with  constraint  blocks  shown 


Real 
Real 
determined :  Real 


Georgia 
Tech 


CT-7-1 


CT-7.1:  SimpleSat  Parametrics  Tutorial 

req  diagram  showing  requirements  verification  pattern 

req  [Package]  SimpleSat  [  j’gij  SimpleSat  Spec  -  Req  Verification  View  ]  j 


Georgia 

Tecti 


CT-7-; 


Report  No.  SERC-201 1-TR-018 


UNCLASSIFIED 


118 


47 


CT-7.1:  SimpleSat  Parametrics  Tutorial 

par  structure  of  building  blocks  and  subsystems 


par  [Block]  MarginBlock  [  definition  J  | 


concept  (generic):  (a)  expanded/flattened  view 

pv  IThockl  FmFerSviteml  ^riffUton  .  vrew  2  |  J 


rl :  margmEqn 

{margin  =  alw/cttm  - 1 } 


:  ^ 

«comment> 

MarginBlock  overview  (aka  margin  of  safety) 
margin  >=  0  means  it  passes. 

margin  value  *  1 00%  =  what  percentage  of  the 
determined  value  is  left  before  you  reach  failure. 

i.e.  margin  =  (alw-det)  /  det 

Example: 

alw  =  200 
det  =  150 
margin  =  0.333 

(i.e.  you  can  increase  det  by  33%  =  50  before  you 
reach  margin  <  0  =  failure). 

This  form  assumes  you  want  determined  < 
allowable,  (i.e  .allowable  is  a  max  Allowable).  It  could 
be  generalized  to  handle  minAllowable  case  also. 

See  also: 

http:  lien  .Wikipedia  ,org/wiki/Factor_of_safety 
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(b)  encapsulated  view 


1  pj 

regWorHknC owes : 

jas=g| 

— 

& F- 

CT-7-31 


CT-7.1:  SimpleSat  Tutorial 

SysML  par  view  and  ParaMagic  tool  for  execution 


{S  ParaMagic(TM)  15.5  spl  -  simpleSatOl 


-=!QJ-XJ 


m 

M0l1«KhKPW6W  •  fxtliiw 


“Object-Oriented  Spreadsheet” 
plus  more ... 


•  Satellite 
E-B  controllerSubSys 
h*  mass 
[  ®  power 
r-  9  powerRating 
|  E-B  reqVerifierRating 
j 9  allowable 

j . 9  determined 

! . 9  mos 

E"  ®  instruments 
[  -9  mass 
i  9  power 

j . 9  mass 

E-B  powerSubSys 
f~®  mass 
J-9  power 

j  E-B  reqVerifierPower 

|  j . 9  allowable 

9  determined 


E®  propulsionSubSys 
h®  mass 
1  •••  9  power 
E-B  reqVerifierMass 
f -®  allowable 
9  determined 


Jd 


Type_ j  Causality  |  Values  | 


Satellite 
ControlSystem 
REAL 
REAL 
REAL 

MarginOfSafetyBlock 

REAL 

REAL 

REAL 

Instruments 

REAL 

REAL 

REAL 

PowerSystem 

REAL 

REAL 

MarginOfSafetyBlock 

REAL 

REAL 

REAL 

PropulsionSystem 

REAL 

REAL 

MarginOfSafetyBlock 

REAL 

REAL 


given 

ancillary 

given 

ancillary 

ancillary 

target 

given 

given 

ancillary 


given 

ancillary 

target 


2,000 

2,000 

9,900 


10,000 

8,980 

0.113585.. 


10,000 

9,900 


L®  mos 

REAL  target  0.010101... 

Expand  | 

Collapse  All  |  Solve  |  Reset  |  Update  to  SysML 

reqVerifierPower 

( Margii 

Name 

Local  | 

On... 

Relation 

Active  | 

rl 

Y 

mos=allowable/determined-l  .0 

[7 
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CT-7.2:  Requirements  Verification  in  FireSat 

Sources:  INCOSE  SSWG  and  InterCAX  LLC;  Georgia  Tech  ASE  6006  NGDMC 


CT-7.2:  Req.  Verification 

in  FireSat  SysML  model 
(including  operational  costs,  etc.) 


“DNA  signature”  auto-generated 
from  SysML  parametrics  model 
(CT-11 ) 


v  #  f 

oJ.®-  — — 

SU  ^  1 


w  .  S 

a 


Model  source:  Dirk.Zwemer@lnterCAX.com 


FH  nigj&di 

r~7!  rfWff.TqrFmdtf 

-HU  faftODWt 
-I  #J  ItwfrdiCfctt 


f 

i  l~*l  yw  ifr  aftr<nt 
BhCDlMK*i  r* 

dl  Atiidf 
-t  ‘IwtAdUabi* 
Ol™lnd 

-O 

a  vtAwt-f1 
tt-CSlKtK*san 

cniwuui 

j-£*l  Soul  P  rr,Vrr  t  y 

I  G3 

i  CflfMKm* 

I  LUlr^tWMf 
— m  MtufonM 
H3MinHt(0K 

—  I  ?iu«6w*4ut 

1  r?l  gw 

15-1 

SQ]^ 

I^QfCnreOvi 
EH  (Il'SjCVi 
1  m  ifitfiKt 


Fhrtnt  J%™ui  ( Hram  j 


5*Mt.H_EJoim‘iLJ  .tj 


wlwV 

xyiarr 

\M0t 


bm 

■  ■^‘jatshr-Juti 

SEAL 


ft.lVi 

Kill 


I  nrv.-f  |  I  tn  =HrJ*  | 


rw] 

Lt*d|  .4  RbUbuii 

I^H 

K£ 

V  P  LmWr^VeiyV-^*r™dOt^-^ 

P 

£ 

IjliYij  IV  pitot;  :■■ 

“Sri 

\U*£*t  f 

fct- 
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CT-8.1a:  Unit  Test/Verification  Pattern 

Verifying  SysML  model:  Linkage  Systems 


Georgia 

EUT  =  entity-under-test 
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CT-8.1a:  Unit  Test/Verification  Pattern 

Verifying  SysML  model:  Linkage  Systems 


(UT)  unit  test  pattern:  DNA  signature  view  (CT-11 ) 


(EUT)  system  design  model 
being  verified 

£ 


(TPj)  seven  (7)  verification 
test  probes  wired 
onto  system  design 
for  automated  verification 


£ 


_ 


CT-11:  Note  also 
validation  possibilities: 
-Are  disconnected  graphs 
ok  in  this  context? 

-Are  any  other  expected 
relations  (equations) 
missing? 

-Etc. 

_ CT-8-31 
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CT-9.1 :  Multi-Unit  Test  (Verification  Suite) 

CT-11:  “DNA  signature”  auto-generated  from  SysML  parametrics  model 


(MUT)  verification  pattern:  multi-unit  test 
(rolling  up  above  unit  test  applied  to  two  designs) 


\U /////+? 


(EUT-i)  system  design  model  -  config  1 


CT-9-21 
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[Part  3]  Contents  B 

•  Core  embedded  V&V  concepts 

[CT-1  to  CT-5] 

•  Higher-level  concepts  -  round  1 

[CT-6  to  CT-1 1] 

-  Sample  SysML-based  V&V  building  blocks 

-  Example  applications 

A  •  Higher-level  concepts  -  round2 

[CT-12  to  CT-1 5] 

-  Verifying  external  models  &  systems  via  SysML 

•  Higher-level  concepts  -  round3 

[CT-16  to  CT-17] 

-  MIM  architecture  for  M&S  patterns 

-  Other  concept  extensions 

Georgia 

Tech 

_ fPart  31 105 

CT-12:  Example:  Two  Spring  System  Tutorial 

Traditional  Mathematical  Representation 

Source:  http://eislab.gatech.edu/pubs/conferences/2007-incose-is-1-peak-primer/ 

System  Figure 

k2 

• - AAA/ - 

>-  Uj  ->-  U2 


Free  Body  Diagrams 


m 


■A/W 

k, 


AL1 

F2 


■AAA/ — 


al2 


Kinematic  Relations 
Constitutive  Relations 


Variables  and  Relations 

rn\Lx=  xl2  -xn  bcl:xn=  0 


ru  :  Fl  =  klALl 


r23 :  F2  =  k2AL2 


bc2 :  jc12  =  x21 
bc3  :Fl=F2  4 
bc4  :F2=P 
bc5 :  =  ALj 

bc6 :  w2  =  AL2  +  ux 


Boundary  Conditions 
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ParaMagic  Core  Solver:  Mathematica 

Mathematica  Job  —  SpringSystems 


(a)  Input  script 

(auto-generated  from  ParaMagic) 
example  2,  state  1.0  (unsolved) 


solutions  =  Solve [  { 
qlSMiklO, 
ql6^oll*5.5, 

014^1$, 
i8— — )9-h7 , 

10==kl0, 

pl5:^yi*0, 

lll?s~j»12+nl3, 

g6=~h,7 , 

kl(M*W.2*6, 

ml^feL8-8, 

ol^»-8 

}  II 

WriteString [  output, 

ToString [  CForin  [N  [  solutions  ]  ]  ]  ]; 

Close [output] | 

Exit [ ] ; 


(b)  Output  script  (results) 
(auto-imported  back  into  ParaMagic) 

example  2,  state  1.1  (solved) 


List (List ( 

Rule(g6, 9.818181818181818)  , 
Rule (h7, 9. 818181818181818)  , 
Rule(i8, 9. 666666666666666) , 
Rule(j9, 19. 48484848484848)  , 
Rule (klO, 10 . ) , 

Rule (ml2, 1.6666666666666665) 
Rule (111, 3. 484848484848485) , 
Rule (nl3, 1.8181818181818183) 
Rule (014,1.8181818181818183) 
Rule  (pi 5, 9.818181818181818) , 
Rule (ql6, 10 . ) ) ) 

)  ) 
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Note:  ParaMagic  16.9  supports  either  of  these  as  a  core  solver  (in  production  releases):  Mathematica  and  OpenModelica. 
Support  for  Matlab  Symbolic  Math  Toolbox  (SMT)  as  a  core  solver  is  WIP. 


CT-12-6 


ParaMagic  Core  Solver:  OpenModelica 

OpenModelica  Job  —  SpringSystems 


(a)  Input  script 

(auto-generated  from  ParaMagic) 


(b)  Output  script  (results) 
(auto-imported  back  into  ParaMagic) 


example  2,  state  1 .0  (unsolved)  example  2,  state  1.1  (solved) 


class  SpringSystems991034 

Real  e4; 

DataSet:  aO 

Real  i8; 

0,  1.81818181818182 

Real  111; 

DataSet:  klO 

Real  aO; 

0,  19.48484848484849 

Real  klO; 

DataSet:  ml2 

Real  ml2; 

0,  9.66666666666667 

Real  bl; 

DataSet:  bl 

Real  d3; 

0,  3.48484848484849 

Real  pl5; 

DataSet:  pl5 

Real  f5; 

0,  1.66666666666667 

Real  ol4 ; 

DataSet:  ol4 

equation 

0,  9.81818181818182 

10.0=111; 

DataSet:  e4 

P15=ml2-8 . 0 ; 

0,  10 

111  pl5*6.0; 

DataSet:  i8 

i8=f 5-8 . 0 ; 

0,  1.81818181818182 

bl=pl5+a0 ; 

DataSet:  111 

ml2=kl0-ol4; 

0,  10 

f 5=d3-0 . 0 ; 

DataSet:  d3 

i8=a0; 

0,  9.81818181818182 

e4=lll ; 

DataSet:  f5 

e4=i8*5 . 5 ; 

0,  9.81818181818182 

d3=ol4 ; 

end  SpringSystems991034 ; 

Georgia 
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Note:  ParaMagic  16.9  supports  either  of  these  as  a  core  solver  (in  production  releases):  Mathematica  and  OpenModelica. 
Support  for  Matlab  Symbolic  Math  Toolbox  (SMT)  as  a  core  solver  is  WIP. 
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ParaMagic  Core  Solver:  Matlab  SMT 

Matlab  Symbolic  Math  Toolbox  (SMT)  Job  —  SpringSystems 


(a)  Input  script 

(auto-generated  from  ParaMagic) 
example  2,  state  1.0  (unsolved) 


(b)  Output  script  (results) 
(auto-imported  back  into  ParaMagic) 

example  2,  state  1.1  (solved) 


syms  aO  bl  d.3  f5  i8  klO  ml 2  ol4  pl5; 

EqQ=a0- (i8)  ; 

a0=  1.81818182 

Eql=d3-0- (f 5)  ; 

bl=  3.48484848 

Eq2=f 5-8- (i8)  ; 

J  9. 81818182 \ 

Eq3=i8 .*5.5- (10)  ; 

f5jJ  9.81818182 

Eq4=kl0-ol4- (ml2) § 

i8=  1.81818182 

Eq5— atl2-8-  (pl5)  ; 

kl0=  19.48484848 

Eq6=ol4-  (d.3)  ; 

ml2=  9.66666667 

Eq7  plSfaO- (bl) ; 

ol4=  9.81818182 

Eq8=pl5 . *6- (10) ; 

pl5=  1.66666667 

[aO  bl  d3  f 5  i8  klO  ml  2  ol  4  pl5]  = 

solve  (EqQ,Eql,Eq2,Eq3,Eq4,Eq5,Eq:6?3Sq!ly3lq8)  ; 

Georgia 
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Note:  ParaMagic  16.9  supports  either  of  these  as  a  core  solver  (in  production  releases):  Mathematica  and  OpenModelica. 
Support  for  Matlab  Symbolic  Math  Toolbox  (SMT)  as  a  core  solver  is  WIP. 


CT-12-8 


CT-13.1:  Home  Heating  System 

Wrapped  Matlab/Simulink  Model  -  SysML  Structure 


Georgia 
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EUT  =  entity-under-test 

Based  on  original  models  by  InterCAX  LLC  and  MathWorks. 
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CT-13.1:  Home  Heating  System 

Sample  Matlab/Simulink  Results 


Georgia 

Tech 


(S)  SysML-wrapped  system  dynamics  model 
(home  heating  system  in  Matlab/Simulink) 


CT-13-2 


CT-13.1/CT-8.1b:  Home  Heating  System 

Wrapped  Matlab/Simulink  Model  -  V&V  Pattern 


verification  pattern:  unit  test  (UT) 

(two  SysML  diagrams  to  visualize  same  model) 


(EUT)  SysML-based  system 
model  w /  external  sim  S 


(UT)  unit  test  s 


(EUT)  SysML-based  system 
model  w/  external  sim  S 


:r 

* — 

Ss\ 

A 

(TPj)  six  (6)  verification 
test  probes  wired 
onto  system  design 
for  automated  verification 


Example  scenario:  You 
are  acquiring  external  sim 
S,  and  you  setup  SysML- 
based  unit  test  wrapper 
UTtoaid  V&V  ... 


Georgia 
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EUT  =  entity-under-test 

SysML-based  V&V  added  around  original  models  by  InterCAX  LLC  and  MathWorks. 


CT-13-v 


Report  No.  SERC-201 1-TR-018 


UNCLASSIFIED 


129 


58 


Report  No.  SERC-201 1-TR-018 


UNCLASSIFIED 


130 


59 


CT-14.2:  Connecting  a  System  Model  to  I 

Domain  Models  (MCAD/ECAD)  via  SysML 

Title:  Composable  Mission  Framework  for  Rapid  End-to-End  Mission  Design  and  Simulation 
Principal  Investigator:  Dr.  Manas  Bajaj,  InterCAX  LLC 

Phase  1:  Jan-Jul,  2009  [NASA  SBIR-08-1-S4.02-9130]  —  NASA  SBIR  project 

Technical  Abstract:  The  innovation  proposed  here  is  the  Composable  Mission  Framework  (CMF) — a 
model-based  software  framework  that  shall  enable  seamless  continuity  of  mission  design  and  simulation 
from  early  stage  advanced  studies  to  detailed  mission  design  and  development.  The  uniqueness  of  our 
approach  lies  in  using  an  open  standard  for  systems  modeling  and  design  (SysML)  to  wrap  mission  models 
including  the  mission  development  process  thus  providing  a  coherent  map  of  mission  knowledge. 

InterCAX's  Composable  Object  technology  provides  the  backend  wrapping,  model  management,  and 
simulation  orchestration  capabilities  to  the  visual  SysML-based  mission  model  at  the  front  end. 

The  Composable  Object  technology  has  already  demonstrated  the  ability  to  power  SysML- 
based  models  with  math  simulation  capabilities  for  early  design  stages.  ParaMagic  is  a  commercially 
available  tool  being  used  by  early  adopters  of  SysML  at  JPL.  The  Composable  Object  technology  has  also 
demonstrated  the  ability  to  associate  detailed  design  and  simulation  models  such  as  those  created  in  CAD 
and  FEA  tools.  However,  a  big  gap  exists  in  the  SysML-based  world  for  conceptual  system  design  and  the 
detailed  system  design-based  world.  If  the  detailed  system  design  and  simulation  models  could  be  wrapped 
as  SysML  objects  and  the  simulations  and  workflows  orchestrated  by  the  Composable  Object  technology,  it 
will  cover  the  entire  gamut  of  complex  system  modeling  and  analysis  world  from  trade  studies  and 
optimization  to  project  scheduling. 

The  key  objective  of  Phase  1  is  to  wrap  both  conceptual  and  detailed  system  design  and 
simulation  models  as  SysML  objects  which  has  not  been  done  before,  and  to  demonstrate  continuity  of 
Q^^^n  concepts  from  simple  to  detailed  implementation. 
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cSy$tem  Design  &  Analysis 
Integrating  and  Executing  Diverse  Models 


CT- 14-31 


CT-14.2 


bdd  [Package]  MiniSatellite_SE_Model  [  [gj  Model_SysML_BDD  ]  | 


Connecting 
system  model  and 
domain  models 


PCA  =  printed  circuit  assembly 


PCB  =  printed  circuit  board 
(bare  substrate  w /  metal  traces  .. 


BGA  =  ball  grid  array 

(a  type  of  electronic  component) 


MCAD 


«block» 

MiniSatellite 


values 

wSat :  Real{Satisfies  =  MinSat_Weight_Req  _1 ) 
cSat :  RealfSatisfies  =  MinSat_Cost_Req_1 } 
weight_req_verdict :  Real 
cost_req_verdict :  Real 

constraints 

wSatCalc :  propertyAdd 

weight_verification  :  if(w>50,0,1){Refines  =  MinSat_Weight_Req_1 ) 
cost_verification  ;  if(c>1 000,0,1  ){Refines  =  MinSat_Cost_Req_1 } 
cSatCalc :  propertyAdd 


[-instrComp 


«block» 

Instrumentation 


values 

wlnstrumentation :  Real 
clnstrumentation :  Real 
constraints 
wlnstrCalc :  InstrCalc 
clnstrCalc :  InstrCalc 


r — ■ — 1  :  i 

rr — — n 

:powerComp 

;CommandComp 

«block» 

«block» 

«block» 

PowerSystem 

Command 

ControlSystem 

values 

wPower :  Real 
cPower :  Real 

values 

wCommand :  Real 
cCommand :  Real 

values 

wControl :  Real 
cControl :  Real 

«block» 

PCA 


wPCA :  Real 
cPCA :  Real 

constraints 

wPCACalc :  PCACalc 
cPCACalc :  PCACalc 


-pcbComp 


«block» 

PCB 


wPCB :  Real 
cPCB :  Real 


•bgaCompsTyi 


«block» 

BGA 

values 

O 

weight :  Real 

moldHeight :  Real 

cost :  Real 

«block» 

BoundingBox 


values 

Real 
y :  Real 
Real 

tolerance  :  Real  =  0.01 


ECAD 
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CT'14System  Model”-  “X  Domain  Model”  Integration 

Ex.  for  X  =  Mechanical  CAD 


Systems  Engineering  Domain  >  /  Design  Domain  N 


Step  la  Create  a  system  model  (e.g.  with  MagicDraw  SysML) 

Step  lb  Create  a  CAD  domain  model  (e.g.  with  Siemens  NX) 

Step  2  Import  the  CAD  model  into  SysML  as  a  CAD  Model  block 

Step  3  Connect  (map)  the  CAD  model  to  the  system  model  using  SysML  parametrics 

Control  an  auto-synch  process:  updates  in  CAD  model  <->  updates  in  system  model 

_ CT-14-5 
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CT-14.2  ParaMagic  is  used  to  execute  the  resulting  total  model.  It  computes 
system-level  cost  &  weight  from  all  nested  subsystem-level  &  component-level 
models  (originating  from  M/ECAD/...  tools),  and  it  verifies  related  requirements. 


File  Edit  View  Layout  Diagrams 
’EfeCo..]'  j&Inhe.f  *0pia.,  [  .  Mo..  | 


□  Data 

b-  y  Relations 
b-B  BGA_NX_Model 
b  Cj  MD  Customization  for  SysML  [MD. 
b-  Ep  MiniSat_SE_NX_Model_Mapping 
EB-  y  Relations 

|  j  &  QCXI_heading 
I  I  l-X  ■■  MmiSat_SE_IMX_Model_l 
:  X  :  MiniSat_SE_NX_Model_l 
!  IB  El  NX_SysModel_Mapping_Ir 
Hg  SysML_NX_Mapping_Inst. 
EB-Q  CXS_heading 
!  MiniSat_SE_NX_Model_Mappii 

L  g  MiniSat_SE_NX_Model_Mappit 
b-fe  MiniSatellite_SE_Model 
b-Ea  UML  Standard  Profile  [UML_Stanc 
b-EB  ParaMagic  Profile  [ParaMagic  Prol 
SysML  Profile  [SysML  Profile.mdzi 
b  '  NX_Connection_Package  [!  ,  kag 
J  Code  engineering  sets 


_.NFO  :  Successful  in  updating  SysML 
'distance. 


!S  ParaMagic(TM)  16.0  Jnstances_ 


Name 

•  MiniSat_SE_NX_Model_Mapping 
[B~®  modelNX 
0- •  modelSE 
h*cSat 

IB  ®  commandComp 
0-i®  controlComp 


Type  Caus...  Values 

MiniSat_SE_N... 

Ball_Grid_Arra. . . 

MiniSatellite 
REAL  target 

Command 
ControlSystem 
REAL  target 

Instrumentation 
PowerSystem 
REAL  target 


iysML_NX_Mapping_Inst_BDD 


REAL 


target 


Weight  requirement  satisfied 


Cost  requirement  not  satisfied 


|  Expand  ]|  Collapse  Al 


|  Reset  ||  Update  to  SysML  ~| 


modelSE  ( MiniSatellite ) 


Name  Local 
wSatCalc  Y 


Relation  Active 

w5at=instrComp.wInstrumentation+powerComp.wPow. . . 


B  weight req verdict=if(w5at  >50, 0, 1) 


cost req verdict=if  (cSat  > 1 000, 0, 1 ) 


cSat=instrComp .  clnstrumentation+powerComp  ■  cPower , , 


«block» 

Ball  Grid  Array  Chip  Pa 


II  Grid  Array  Chip 


CHIP_1 01  =  CHIP_1 01 
HEAT_SINK_1 01  =  HEAT 
MOLD_1 01  =  MOLD  _1 01 
SBA_1 01  =  SBA_1 01 
SUBSTRATEJ  01  =  SUE 


bodySurfaceArea  =  "0.084 
bodyVolume  =  "2.000000C 
length  =  "0.2" 
surfaceArea  =  "0.0440000 
thickness  =  ”0.0050" 
weight  =  "5.658000000001 
width  =  "0.2" 


I  L 

1 1™ 
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CT-14.3:  Live/Virtual/Constructive  Simulations  (LVC) 

Representative  Toolset:  STK  (www.agi.com) 


Supplemental 
STK  Modules 

Modeling  E 

Platforms 

•  Aircraft  Mission  Modeler  I 

•  Missile  Modeling  Tools 


VS 

a  a  b  a  a 


•  Astrogator 

■ 

•  Attitude 

■ 

Payloads 

•  Communications 

• SATSOFT 

■  ■ 

•  EOIR 

■  ■  ■ 

•  Radar 

Environment 

•Terrain,  Imagery  &  Maps 

•  TIREM 

■  ■■ 

•  Urban  Propagation 

•  GIS  Analyst 

■  ■  ■ 

■  ■  ■  ■ 

•SEET 

•RAE 

•  Weather  Sentinel 

■ 

■  ■  ■ 

Analysis 

•  Analyzer 

•  Optimizer 

•  Coverage 

■  ■■  ■■ 

•CAT 

•  Scheduler 

■ 

■ 

CT-14.3:  System/SoS  M&S 
Examples  in  STK 

Geo-positioning  Model 


Force-on-Force  Fighter  Simulation 


(a)  Normal  model  view 


Missile  Launcher  Model 


(b)  Marker  &  trajectory  history  view 


Georgia  '.afifSiC'S* 

Tech 


(a)  Link  with  ground  station  at  t=t1  (b)  Link  with  ground  station  at  t=t2  (c)  Link  broken  with  ground  station  at  t=t3 
(several  orbits  after  tl )  M  0  minutes  after  t2)  qj-|  4-|  q 
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CT-14.3:  Two-way  interoperability  SysML-STK  (throughout  simulation  run-time) 
-»  Changeable  inputs  (SysML  to  STK):  satellite  and  ground  station  properties 
Results  (STK  to  SysML  ):  duration  of  ea.  link  session  with  ea.  ground  station 

STK  satellite  comm,  link  sim 


had  P-»W]  If  hCbme  1 i  J. 


STK  wrapper  instances 


^  P 

r.Mj^rmmdnKXPdiiBMEldS  ■  "3lM 

-> 

<(*>g(AlTtdrt*W#f1ttWDS0«'3M  7M2- 

— > 

sat  nRhjr^-7  71i«r-fr 

EaLCUHs4cMon  *  'U- 

— > 

&aLCl3B**tMon  -  ‘U- 

— > 

sa_e<t*jidicfr*,9  my-  v 

taLfilBmemMumStr  t  'TSiM' 

— > 

ta^lamanWdmDt  r  *■  -750*  .IT 

suu&p&tii  =  -<iSn  i  S 

— > 

satjne  Itfia&flnDag  ±  *61  64' 

f  ^  5 

■satjHicHnaHonDag  =  'fl.flr 

■jO^IhrnaWriailWirilgnndJr  *  -*JHIM1jr*r 

saLWeanAnomatyGeg  **  '1 62  4  749“ 

|  — > 

saLHsanAnomatyOen*  "1 62  left's1 

f.dUJi'nnttTrtioni'lir 

^M^MpdnMWtKira-'iri  IT 

sat_V*  anMertinniflffl  ■  26r 

sat.Uf  arrtMinrSol  =  ■SME-fr 

■  "IT 

thiJrit  hnUaUhneiiSSJW  ■  'fl  tr 

^aLWima  ^ -lc  aru  jCrtltaWInrar 

|  — » 

saLWjma  fitiruaOrtmfl*Mirr«' 

«H_Hi*vWLdi6nHuir«ntftl£pn£H  -  -HfltflK- 

r..it_H''>nruiirinfJiin-iJW'(hlI-phc  hi  -  ■‘Ml  SB  dr 

sat  ,RigtitftstensUmO»gcenainoHDdBDBg  = 

sat  .Highest  Bn9iwOWse?!inipiBNpdBDBg  & 

«Ce»mtirt4«e*'r 

3n[J3&h5*itBWyrrrti<H  =  ’ll  dr 

ftBflW0IWjl<*T-2T 

P  ^  - 

aftaHpn0luf.Wi-.204r 

Sl3bmfllu*Jir*0i>*aB,hn_s  :  TT 

SihtKjnHiufijintiOurafiflti  1 1  -i  hJft  dr.-i  dr,  -i  a?i>  O', 

slatKKiGluflenjfW 

■132B  4T,  'I  B204T.-1 6204T.'1 620  (T.  "1 620  (T.  '1 620.0- 

■t.1  ah  rt«*  R 1 1 1*  i  rA-tbiMQ  n  ft  n  g  :  TIT 

rt1ahrtnHlu*Jrt*ig, ,  'l?7tr 

aWOnOBWn.lif-'Z' 

r'flHbiW0lur_mlnCteviH(jnDug  =  Jfl.lT 

3ttfi0n0«Mr>JiiiHOiiri1i«n,l  =  tr 

— > 

slabtsnOffcanjar  -  "2  U 

^IntKmt^fWinJnnn  a  ’  7t.(r 

-.Inbr.hi  Ih’-r-n  linM  :-;ir.Hif.n  .A  i '121111  (T.'ljth  IT, 

s laac'nMe er  mmElevadcnpag  =  Mr 

■121 5  IT,  -1 21 54T.  -1 21 54T/1 2H0  F,  "1 200  4T.’  1 3fll(T 

^1anonna9.ftn.jnr.D  --tr  cr 

's|aa<m0hVdi5.  mlnEluvaHbnCwg  =  “■■  1 04T 

rJurgre  irtm  acimria  Id  1*5 1  1 
i  Fiutrg  isp  hi  nM'.Ird  «Mxi 

dmtffamJtSvWVU  ItiSd  *  IfiQSfl 
id  rwirnd  hti  hwf  slra.tmed  l 
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CT-15:  Mobile 
Robot  Context 


Myro  rover 

(a  cyber-physical  system) 

CT-15:  Towards  automating 
verification  and  T&E  of 
physical  systems  ... 


—  ^1 

'll-  t 

cioti -wni 

a  Tw  MjHd 

Gelling  to  Know  Your 
1PRE  Fluke 


Georgia 

Tech 


CT-15-ll 
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CT-15:  Scribbler  /  MyroMagic  Demo 

Executable  SysML  Activity  Model  [2  -  after  live  update] 


Sl::;; 


ca  T  -  e? 


B  -  S  MyroMagic_Primer 

F^  ri  MyroSoftwarePlatform 

ModeAC_Activities 
|  i'Q  DecisionNodeTestl 

-  <>  gBBBBB 

&■■■■?  Relations 

j . O  fwl  :GoForward 

|  O  trl:TurnRight 

I . O  fw2:GoForward 

I . O  tr2:TurnRight 

i . O  fw3:GoForward 

| . O  tr3:TurnRight 

| . O  fw4:GoForward 

. •  start 

j . «§■>  end 

I . O  tr4:TurnRight 

j . O  nl:ShowSensorsStatus 

j . O  n2:Beep 

j . O  n3:Beep 

j--Sl  PerformMissionSquare 
j  E&-CJ  PerformMissionUturnispecif 
B-  n  ModeAC_OpaqueBehaviors 
[••••$/)  Beep(specifies  beep) 

E|}  GetBatteryLevel(  result ) 

GoBackward(specifies  goBa  r 
f  GoForward( specif ies  goFon 


Resulting  python  script  - 
(simplified  view) 


«SBIV 


rt  [Activity]  PerformMissionSquare  [  [r^j  PerformMissionSquare  ]  | 


from  myro  import  * 
initialize("com29") 

senses() 
beep(1, 440) 
forward(1, 1) 
turnRight(1,  .4) 
forward(1, 1) 
beep(1, 440) 
turnRight(1,  .4) 
forward(1, 1) 
turnRight(1,  .4) 
forward(1, 1) 
turnRight(1,  .4) 


--H1 


2*. 


ShowSensorsStatns 


H -"L  n’!~p* 


tr2 :  TurnRighjt 


■i 


-opaque  behaviors  (native  code  segments) 
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[Part  3]  Contents 

•  Core  embedded  V&V  concepts  [ct-i  toci-5] 

•  Higher-level  concepts  -  round  1  [CT-6toCT-ii] 

-  Sample  SysML-based  V&V  building  blocks 

-  Example  applications 

•  Higher-level  concepts  -  round2  [CT-i2toCT-i5] 

-  Verifying  external  models  &  systems  via  SysML 

4*  Higher-level  concepts  -  round3  [CT-i6toCT-i7] 

-  MIM  architecture  for  M&S  patterns 

-  Other  concept  extensions 

Georgia 

Tech 

[Part  3]136| 
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CT-16:  Modeling  Interoperability  Method  (MIM) 

Example  System  Design  &  Simulation  Applications 

Applications  /  Projects  -  Completed  (-1999-2009) 

•  Excavator  systems  [including  mfg] 

•  Airframes  -  structures 

•  Electronics  -  circuit  boards 

•  Electronics  -  chip  package  design  &  analysis 

•  Mechanical  assemblies  -  part  design  &  analysis  (benchmark  tutorial) 

Applications  /  Projects  -  Partially  Completed 

•  Space  systems  -  satellites,  etc.  (FireSat,  etc  ) 

•  Automotive  -  steering  wheel  systems 

Pro  Forma  Applications 

•  Airport  management  -  security/emergency  response 

•  Building  management  -  security/emergency  response 

•  Naval/marine  ships  [including  operation] 

•  UAVs  -  -C4ISR  [including  mfg] 

•  Firefighting  -  communication  systems  -  -C4ISR 


Excavator  Modeling  &  Simulation  Testbed 

Interoperability  Patterns  View  (MSI  Panorama  per  MIM  patterns) 


aO.  Descriptive  Resources 

(Authoring  Tools,  ...) 


dO.  Simulation  Building  Block 


eO.  Solver  Resources 


Cost 

Concepts 


Excavator  Sys-Levei  Models 


C*3 


System  &  Reg  Tools 


f  Reliability  \  f  Sold  h 

fftaeSjts  J  |  Mechanics  | 


”  Queuing 
Concepts 


Optimization  Model 
T  Objective 
[  Function  J 


bO.  Federated 
Descriptive  Models 


Excavator  Domain  Models 


Federated  Excavator  Model 


f  Operations  ]  j  Hydraulics  j _ 

[Subsystem  J 


Reliability 

Model 


Generic  Math  Solvers 


Boom  Linkage  Models 
Stress/Deformation  Models 


Extensional 
Linkage  Model 


Sys  Dynamics  Solvers 
Dymola 


[  Dig  Site  J  [pump  Trucks^ 


Factory  Domain  Models 


Plane  Stress 
Linkage  Model 


Federated  Factory  Model 


(  Req.  &  Excavator 
(  Objectives  J  (  MBOM  J~ 


Boom  Mfg.  Assembly  Models 
Assembly  Process  Models 


MM1  Queuing 
Assy  Model 


Discrete  Event  Solvers 


Discrete  Event 

1 

eM-Plant  / 

Assy  Model 

Factory  Flow 

Notes 

|j|J| 

5  E  2  5  3 


SHI! 

is  IU 
If  Iff 
mp 

||ll| 

s  |  It 
i  % 


I  STS 
!  2  ? 


Hi 

III 
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MIM  Panorama  for  Naval/Marine  Vessels 

Ship  Design ,  Analysis,  and  Operation 

(pro-forma) 


cO.  Context-Specific  Models 

* - 1 

cl.  Simulation  Templates 
Resources  T  Building  Blocks  (of  diverse  behavior  &  fidelity) 


aO.  Descriptive 


c2.  Optimization  Templates 

kaw 


dO.  Simulation 


< 


i 


- Parametric  associativity 

- ►  Tool  &  native  model  associativity 

- -»  Composition  relationship  (re-usage) 


eO.  Solver 
Resources 


ECAD  &  MCAD  Tools 

Tribon,  CATIA,  NX,  Cadence, 


Evacuation  L 
Mgt. 


Systems  &  Software  Tools 

DOORS,  E+  ^ 

MagicDraw,  :> 

Studio,  Ull 
Eclipse,  ... 


Operation  Mgt.  Systems 

I 


Libraries  &  Databases  — 

Classification  Codes,  Materials, 
Personnel,  Procedures,  ... 

Georgia 

Tech 


Evacuation  Codes 

— ►  Egress,  Exodus,  ... 


General  Math 

Mathematica, 
-*■  Maple,  Matlab ... 

CFD 

Flotherm,  Fluent,  ... 


bO.  Federated 
Descriptive  Models 


FEA 

Abaqus,  Ansys, 
Patran,  Nastran,  ... 

m 

Discrete  Event 

Arena,  Quest,  ... 

CT-16-31 


MIM  Panorama  for  Building  Management 

Building  Emergency  Response  /  Model-Based  Security  —  Design/Analysis/Operation 

(pro-forma) 


aO.  Descriptive  Resources  dO.  Model 

Building  Block  Libraries 

CAD  Tools 

CATIA,... 


Facilities  Mgt.  Systems 


cO.  Context-Specific 
Simulation  Models 

(of  diverse  behavior  &  fidelity) 

Evacuation 


eO.  Solver  Resources 

Evacuation  Codes 

Egress,  Exodus,  ... 


Libraries  &  Databases 

Materials,  Equipment 
Personnel,  Procedures,  ... 


Legend 

- ►  Tool  Associativity 

- >  Object  Re-use 


bO.  Federated  Descriptive  Model 


FEA 

MSC Nastran,  ... 

u  sse  1 1 .  Pea  k@gate  ch .  ed  u  2003-02-28 
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Security  Center  Dashboard 

Overall  Status  of  Key  Systems 


System 

Status 

Crowd  Controls 

© 

Passenger  Screening 

© 

Cargo  Screening 

© 

Communication  Systems 

© 

Electrical  Systems 

© 

HVAC  Systems 

© 

Chemical  Detection 

Biological  Detection 

© 

Source:  Russell. PeaklSJmarc.aat 

:ech.edu  2003-04-24 

MIM  Panorama  for  Airport  Management 

Airport  Emergency  Response  /  Model-Based  Security  —  Design/Analysis/Operation 

ATL  / Hartsfield  Jackson  International  Airport  (HJIA)  (pro-forma) 


aO.  Descriptive  Resources 


dO.  Model 

Building  Block  Libraries 


cO.  Context-Specific 
Simulation  Models 

(of  diverse  behavior  &  fidelity) 

Evacuation 


eO.  Solver  Resources 

Evacuation  Codes 

Egress,  Exodus,  ... 


Libraries 

Materials,  Equipment, 
Personnel,  Procedures, 

Legend 

— ►  Tool  Associativity 
Object  Re-use 


bO.  Federated 
Descriptive  Model 


FEA 

MSCNastran,  ... 


Georgia  -.afStijLMW* 
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MIM  Panorama  for  Electronic  Packaging  -  Ex  1 

Printed  Circuit  Board/Assembly  Design  &  Analysis 

Project:  US  DoD  ProAM,  NASA/JPL  Project,  NIST  SBIR, ... 


aO.  Descriptive  Resources 
ECAD  Tools 


dO.  Model 

Building  Block  Libraries 


cO.  Context-Specific 
Simulation  Models 

(of  diverse  behavior  &  fidelity) 


eO.  Solver 
Resources 


Mentor  Graphics, 


Accel * 


PWB  Stackup  Tool 

XaiTools  PWA-B 


Laminates  DB 


Materials  DB 


WD1.7  '*  =  Item 


:  available  in  toolkit  (all  others  have  working  examples)  **  =  Item  available  via  U-Engineer.com 


XaiTools 

PWA-B  General  Math 

■  -  -  -  -  -  ,  Mathematica 


CT- 16-7| 


MIM  Panorama  for  Electronic  Packaging  -  Ex.  2 

Chip  Packages/Mounting  Design  &  Analysis 

Shinko  Electric  Project:  Phases  1  &  2 


aO.  Descriptive  Resources 
Prelim/APM  Design  Tool 


dO.  Model 

Building  Block  Libraries 


cO.  Context-Specific 
Simulation  Models 

(of  diverse  behavior  &  fidelity) 

XaiTools 
ChipPackage 


warn 


eO.  Solver 
Resources 

General  Math 

Mathematica 

FEA 

Ansys 


Authoring 

MS  Excel 

CT-16-8 
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MIM  Panorama  for  Airframe  Structures  -  Ex.  2 

Lug  &  Fitting  Design  &  Analysis 

Boeing  PSI  Phases  3.0  and  3. 1  (pro  forma) 


aO.  Descriptive  Resources 


dO.  Model 

Building  Block  Libraries 


XaiTools 
FrameWork 

bike  frame”  (flap  support), 
other  parts,  ... 

bO.  Federated 
Descriptive  Model 


cO.  Context-Specific  eO.  Solver 

Simulation  Models  Resources 

(of  diverse  behavior  &  fidelity) 

XaiTools  FrameWork 

1.5D 
Lug: 

Axial/Oblique; 

Ultimate/Shear 


General  Math 

Mathematica 


^  1.5D 

Fitting: 
Bending/Shear 

Generic 
COB  Tool 


LI 

Georgia 
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Analysis  Module  Tools* 

Tailored  Lug  &  Fitting  Tools 
(scalable  idealized  views,  etc.) 


CT- 16-91 


Flap  Linkage  Mechanical  Part 

A  simple  design  ...  a  benchmark  problem. 


This  simple  part  provides  the  basis  for  a  benchmark  tutorial  for  CAD-CAE  interoperability  and 
simulation  template  knowledge  representation.  This  example  exercises  multiple  capabilities  relevant  to 
such  contexts  (many  of  which  are  relevant  to  broader  simulation  and  knowledge  representation 
domains),  including: 

•  Diversity  in  design  information  source,  behavior,  fidelity,  solution  method,  solution  tool,  ... 

•  Modular,  reusable  simulation  building  blocks  and  fine-grained  inter-model  associativity 


See  the  following  for  further  information: 

-  http://eislab.gatech.edu/pubs/conferences/2007-incose-is-l-peak-primer/ 

.  http 

://eislab. gatech.edu/pubs/conferences/2007-incose-is-2-peak-diversity/ 
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Simulation-Based  Design  Using  SysML 


NOTE:  These  papers  use  MRA2 
terminology,  which  MIM  is  based  on  (plus 
generalizations  and  extensions).  See  the 
next  several  slides  for  a  rough  mapping 
between  MRA2  and  MIM  terms. 


Part  1 :  A  Parametrics  Primer 

OMG  SysML™  is  a  modeling  language  for  specifying,  analyzing,  designing, 
and  verifying  complex  systems.  It  is  a  general-purpose  graphical  modeling 
language  with  computer-sensible  semantics.  This  Part  1  paper  and  its  Part 
2  companion  show  how  SysML  supports  simulation-based  design  (SBD)  via 
tutorial-like  examples.  Our  target  audience  is  end  users  wanting  to  learn 
about  SysML  parametrics  in  general  and  its  applications  to  engineering 
design  and  analysis  in  particular.  We  include  background  on  the 
development  of  SysML  parametrics  that  may  also  be  useful  for  other 
stakeholders  (e.g,  vendors  and  researchers). 

In  Part  1  we  walk  through  models  of  simple  objects  that  progressively 
introduce  SysML  parametrics  concepts.  To  enhance  understanding  by 
comparison  and  contrast,  we  present  corresponding  models  based  on 
composable  objects  (COBs).  The  COB  knowledge  representation  has 
provided  a  conceptual  foundation  for  SysML  parametrics,  including 
executability  and  validation.  We  end  with  sample  analysis  building  blocks 
(ABBs)  from  mechanics  of  materials  showing  how  SysML  captures 
engineering  knowledge  in  a  reusable  form.  Part  2  employs  these  ABBs  in  a 
high  diversity  mechanical  example  that  integrates  computer-aided  design 
and  engineering  analysis  (CAD/CAE). 

The  object  and  constraint  graph  concepts  embodied  in  SysML 
parametrics  and  COBs  provide  modular  analysis  capabilities  based  on 
multi-directional  constraints.  These  concepts  and  capabilities  provide  a 
semantically  rich  way  to  organize  and  reuse  the  complex  relations  and 
properties  that  characterize  SBD  models.  Representing  relations  as  non- 
causal  constraints,  which  generally  accept  any  valid  combination  of  inputs 
and  outputs,  enhances  modeling  flexibility  and  expressiveness.  We 
envision  SysML  becoming  a  unifying  representation  of  domain-specific 
engineering  analysis  models  that  include  fine-grain  associativity  with  other 
domain-  and  system-level  models,  ultimately  providing  fundamental 
capabilities  for  next-generation  systems  lifecycle  management. 


Georgia 

Tecli 


Part  2:  Celebrating  Diversity  by  Example 

These  two  companion  papers  present  foundational  principles  of 
parametrics  in  OMG  SysML™  and  their  application  to  simulation-based 
design.  Parametrics  capabilities  have  been  included  in  SysML  to  support 
integrating  engineering  analysis  with  system  requirements,  behavior,  and 
structure  models.  This  Part  2  paper  walks  through  SysML  models  for  a 
benchmark  tutorial  on  analysis  templates  utilizing  an  airframe  system 
component  called  a  flap  linkage.  This  example  highlights  how  engineering 
analysis  models,  such  as  stress  models,  are  captured  in  SysML,  and  then 
executed  by  external  tools  including  math  solvers  and  finite  element 
analysis  solvers. 

We  summarize  the  multi-representation  architecture  (MRA)  method  and 
how  its  simulation  knowledge  patterns  support  computing  environments 
having  a  diversity  of  analysis  fidelities,  physical  behaviors,  solution 
methods,  and  CAD/CAE  tools.  SysML  and  composable  object  (COB) 
techniques  described  in  Part  1  together  provide  the  MRA  with  graphical 
modeling  languages,  executable  parametrics,  and  reusable,  modular,  multi¬ 
directional  capabilities. 

We  also  demonstrate  additional  SysML  modeling  concepts,  including 
packages,  building  block  libraries,  and  requirements-verification-simulation 
interrelationships.  Results  indicate  that  SysML  offers  significant  promise  as 
a  unifying  language  for  a  variety  of  models-from  top-level  system  models  to 
discipline-specific  leaf-level  models. 


Citation 

Peak  RS,  Burkhart  RM,  Friedenthal  SA,  Wilson  MW,  Bajaj  M,  Kim  I 
(2007)  Simulation-Based  Design  Using  SysML.  INCOSE  Inti.  Symposium, 
San  Diego. 

Part  1:  A  Parametrics  Primer 

http://eislab.qatech.edu/pubs/conferences/2007-incose-is-1-peak-primer/ 

Part  2:  Celebrating  Diversity  by  Example 

http://eislab.qatech.edu/pubs/conferences/2007-incose-is-2-peak-diversity/ 


CT-16-11 


MRA2  ^  MIM  0.1  as  Specialized  for 
Design-Analysis  Integration  (DAI) 


Classical  MRA2 

-  c.2000  +  extensions 

-  As  seen  in  INCOSE  IS’07  Part  2 
paper  above,  etc. 

-  Based  on  6  PhD  dissertations  and 
3  Masters  theses  as  of  2008 

|  Design  Tools  |  |  Solution  Tools  J 


Analyzable 

W  Product  Model  (4)  Context-Based  Analysis  Model 


MRA2 

with  MIM  0.1  identifiers 


Georgia 
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bO.  Analyzable  Product  Model  cO.  Context-Based  Analysis  Model 


aO.  Design  Tools  j  |e0.  Solution  Tools] 
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MIM  Panorama  for  Mechanical  Design 

Flap  Linkage  Model — A  Benchmark  Design-Analysis  Example 

Interoperability  Panorama  View  (per  MIM  0.1  terminology) 


a0.  Descriptive  Resources 

MCAD  Tools 

CATIA,  NX,  Pro/E*,  ... 


Requirements  Tools 

DOORS*,  MagicDraw, 
E+,  Rhapsody*,  Studio,  ... 


Parts  Libraries  - 

In-House*,  ... 

jj1  - Parametric  associativity 

*8  - ►  Tool  &  native  model  associativity 

a. - •  Composition  relationship  (re-usage) 


d0.  Simulation 
Building  Block  Libraries 


bO.  Federated 
Descriptive  Model 


In 

irilW 

cO.  Context-Specific  eO.  Solver  Resources 
Simulation  Models 

(of  diverse  behavior  &  fidelity) 
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a0  FlapLinkage  Implementation  in  CATIA  v5 


Start  TeamPDM  File  Edit  View  Insert  Tools 


]a0]] 


1  ®  3+ ™ 


bl\Sketch.  14\Offset.  18\Off 
b2\Sketch.  15\Offset.24\Off 


dy.6\Sketch.  1  l\Offset.  1  l\Offset 
J9*Sleeves\Sketch .  6\Of  f  set .  9\Of  f 


dy.6\Sketch.ll 

»,es\Sketch.6\R 


Formula.  13:  rib3\Sketch .  1 6\Of fset . 30\Of fset=Q . 995*Sleeves\Sketch. 6\Offset . 9\Off set  +Sleeves\Sketch.6\Radius.8\Radius 


rib4\Sketch.  17\Offset.37\Offset=Body.6\Sketch.  1  l\Offset.  1  l\Offset  -(0.999*Body.6\Sketch.  1  l\Radius.7\Radius  ) 
Shaf  t\Sketch .  4\Of  f  set .  1 5\Of  f  set=f  lange  .thickness 
Shaf  t\Sketch .  4\Of  f  set .  1 6\Offset=f  lange_thickness 

Shaf  t\Pocket .  1  \FirstLimit .  5\Depth=Shaft\Pad .  3\FirstLimit .  6\Length  -thickness 
thickness=web_thickness  /2 

Shaf  t\Pad .  3\FirstLimit .  6\Length=f  lange_width  /2  - 

ef  f  ective_l  D_rod\Pad .  1  l\FirstLimit\Length=effective_lD_rod\Sketch,18\Length.45\Length 
Body .  1 2\Pad .  1 2\FirstLimit\Length=ef  f  ecti  ve  length 


-  c)  Sample 
design-idealization  relation  I 


(0) 

la)  Detailed  design 

1  (CAD  model) 

|  ^  fcj 

R 
w 

m 

& 


K 


Qng  S&  EE*  +$*  Ep  %  Jz  8^  l|f]  5|]  0 
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bO  FlapLinkage  Parametric  Design  Relations 

Name 

Constraint 

Constraint  substitution  form 

prl: 

% 

II 

{sleeve  l.origin.y  =  origin.y} 

pr2: 

{ys2  =  ysl  +  L} 

{sleeve2.origin.y  =  sleeve  l.origin.y  +  interAxisLength} 

pr3: 

{hrl  =  (wsl  -  wtd)  /  2} 

{ribl. height  =  (sleeve  1  .width  -  shaft.criticalCrossSection.design.webThickness)/2} 

pr4: 

Is5 

^o 

II 

Is 

Iso 

* 

{rib2. height  =  (sleeve2. width  -  shaft. criticalCrossSection.design.webThickness)/2} 

pr5: 

{trl  =  wtd} 

{ribl. thickness  =  shaft.  criticalCrossSection.design.webThickness  } 

pr6: 

{tr2  =  wtd} 

{rib2.  thickness  =  shaft.  criticalCrossSection.design.webThickness  } 

pirl: 

{Leff=L-(rhsl  + 
rhs2)} 

{effectiveLength  — 

interAxisLength  -  (sleevel. hole. crossSection. radius  + 
sleeve2.  hole.  crossSection.  radius) } 

pir2: 

{htotd  =  odsl} 

{shaft.shaft.criticalCrossSection.design.totalHeight  =  sleevel  .outerDiameter} 

pir3: 

{tha  =  thaf*  Leff} 

{allowableTwist  —  allow ableTwistF actor  *  effectiveLength} 

pir4: 

Georgia 

Tech 

{dLa  =  dLaf*  Leff} 

{allowableln  terAxisLength  Ch  ange  — 

allowablelnterAxisLengthChangeFactor  *  effectiveLength} 

CT-16-17 

bO.  Design  Template  Instance:  Flap  Linkage  XYZ-150 

Executable  parametric  model  in  XaiTools  COB  browser— an  object-oriented  spreadsheet. 


Computed  outputs 
(targets  and  ancillary  outputs) 


Detailed  design  inputs 
from  CAD  and  requirements 
(givens) 


Design  features 
(object-oriented  structure) 


fT  srl!]ln.y>=*3tee>,g1  .QiHiln.y 1  ♦InftsrArJsLeiigmi _ 

v  ■util  heigiiy*  <*5iee>ei  sh an.c K.e alf.'ro«stie t$Qn.de&Bn rinsfoess u 

Y  ri ill?  I •  ■  ■  nj 1 1 1  --—f r '.h imtii ?  ■¥liii!i -  Jl,l‘  ill  me  jlfini  rj  in  lln'^gn  iMiiTiTliiiiirii^iij-if?  n 

t  .<|tti.1l*:«iri»GS»  »shaflcrltlcai!Cfl>sc3et1l«i.d8slgn  wsb-THU Mies  s- j 

■rJh?  Ih<^iift;.-qyg=«"!.hiii>  rfl|li:iil'.R;i !■.!’  iB»  mllrai  iJi>-.;|i)n  m  iliThu  kimi-M* _ 

i:  -r  vt-^l  -ICIE  f*c^=-0e/l  iiri  iSdmir ,  fgs-r:  1C  -  ,.-rc  :,r 

ci.‘  'ilQos^iifiaan  flasran.Ki^lHffiahf-'  •s.ieBvtf  DuteiDiaifielap 

’.jllirwrj teiiTwlv;[x=^.iEg[wililiiTY^;IFMrlYip*'i.' rfurlr’ji'l  i-'iij|Ii-t _ 

Y  'ailnwaBfllrYlBrflHEijanfllhftianipe*  ■  allc'^itJlBicilsrftu&ijenplfithanpah  aeDop"*eti9c[iYELE4i<jlh » 


Parametric  design  relationships 
(multi-directional) 
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cO.  Linkage  Simulation  Templates  and 
dO.  Generic  Building  Blocks 

SysML  Block  Definition  Diagram  (bdd)  -  basic  view 


dO.  Libraries  of  Model  Building  Blocks 

Material  Model  &  Continuum  Bodies 

SysML  Parametric  Diagrams 
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cO.  Analysis  Template:  Linkage  Extensional  Model 

SysML  Parametric  Diagram — Definition  View 


't=r^=TU . 


*  =  emergent  behavior 


condition:  Condition 


reaction: 


description: 


stressMosModel: 

MarginOfSafetyModel 


determined:  Q- 

^  allowable: 

marginOfSafety: 


do 


^  undeformedLength: 
^  area: 


totalElongation: 

length: 


normalStress:  Q 
^  youngsModulus: 

totalStrain:  Q 


force: 


eO 


Solving  supported  via 
math  tool  execution 


CT-16-21 
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MIM  Panorama  for  Mechanical  Design 

Flap  Linkage  Model — A  Benchmark  Design-Analysis  Example 

Interoperability  Panorama  View  (per  MIM  0.1  terminology) 


a0.  Descriptive  Resources 
MCAD  Tools 


dO.  Simulation 
Building  Block  Libraries 


cO.  Context-Specific  eO.  Solver  Resources 
Simulation  Models 

(of  diverse  behavior  &  fidelity) 


CATIA,  NX,  Pro/E*,  . 


Requirements  Tools 

DOORS*,  MagicDraw, 
E+,  Rhapsody*,  Studio,  ... 


Materials  Libraries 

In-House,  ... 


Parts  Libraries  - 

In-House*,  ... 

jj1  - Parametric  associativity 

*8  - ►  Tool  &  native  model  associativity 

a. - •  Composition  relationship  (re-usage) 


◄ - ►  General  Math 

*  Mathematica, 
Matlab*, 
MathCAD*, 


* 


Ansys,  Abaqus, 
CATIA  Elfini*, 
MSC  Nastran* , 
MSC  Patran , 
NX  Nastran*, 


*  =  Item  not  yet  available  in  toolkit.  All 
others  have  working  examples.  Based  on 
HMX  0.1  pattern  terminology.  2008-02-20 


Georgia 
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eO/el .  SysML  Wrapping  for  Native  FEA  Template 

Specialized  ABB  system  with  FEA-based  SMM  template 

(a)  Specialized  analysis  system — SysML  parametric  diagram. 


par  [block]  LinkagePlaneStressAbb  [Definition  view] 


□ - 

Ex: 

Sr 

L: 

□ - 

wsl: 

□ - 

ws2: 

□ - 

rsl: 

□ - 

rs2: 


rl:  CobExternalFunction 

Ljfnl: 

in9: 

□  in2: 

inlO  :p 

□  in3: 

ini  1 :  El 

3]  In4: 

in12:  □ 

^  in5: 

ini 3:  □ 

^  in6: 

outl:  □ 

^3  in7:  t 

out2:  Q 

^  in8.V 

=/rt(L,  wst 

,tS\,rsx,...,E 

Generic  SysML  block  for  wrapping 
external  solver  models  like  (b) 
as a£arametricj^elations^^^^ 


Flap  Linkage  Design  Verification:  System  Context 

SysML  Requirements  Diagram 
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Simulation  Template-based  Test  Case  Execution 
for  Requirements  Verification 


sd  [testCase]  FlapsDownTf  tCasejMtJ  [Instance  view:  test  completed]. 


|s- 

■ 

i 

FEA-based  engineering  analysis  template^ 


«  blocks 

:  FlapLinkageTestBench_245 


«cbam» 

:  LinkagePtaneStressModel_760 


getVerdict(FlapLinkage_XYZ-510); 


setFlapLinkagelnstance(FlapLinkage XYZ-510)  | 

setLoad(:  lbs  =  10000);  executeQ  j  j 


getResultfsxMosModel.marginOfSafety') 


2 


getResult(“uxMosModel.marginOfSafety") 


1 


:  Verdict  =  “pass" 


Georgia 
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[Part  3]  Contents  fl 

•  Core  embedded  V&V  concepts 

[CT-1  to  CT-5] 

•  Higher-level  concepts  -  round  1 

[CT-6  to  CT-1 1] 

-  Sample  SysML-based  V&V  building  blocks 

-  Example  applications 

•  Higher-level  concepts  -  round2 

[CT-1 2  to  CT-1 5] 

-  Verifying  external  models  &  systems  via  SysML 

•  Higher-level  concepts  -  round3 

-  MIM  architecture  for  M&S  patterns 

4  -  Other  concept  extensions 

[CT-1 6  to  CT-1 7] 

Georgia 

Tech 

_ rPart  31166 

Report  No.  SERC-201 1-TR-018 


UNCLASSIFIED 


154 


83 


CT-17:  Other  Ways  to  Aid  Validation 

•  Use  SysML  model  (and  related  views  such  as 
diagrams,  DNA  signatures,  ...)  as  additional 
perspectives  that  SMEs  can  review  and  validate 

•  Can  capture  SME  validation  criteria  to  formalize  it 
as  reusable  knowledge,  to  automate  portions  of 
future  re-validations,  ... 

•  Some  aspects  could  leverage  SysML-based 
comparators,  margin  blocks,  and  similar  concepts 
-  Ex.  Comparing  sim  values  vs.  T&E  measurements 

•  Treat  each  individual  M&S  (and  their  environments) 
as  systems  in  themselves,  and  thus  apply  MBSE  to 
capture/manage/validate  requirements,  etc. 

Georgia 

Tech 

_ CT-17-1 


CT-17  (cont.):  Ways  to  Aid  Accreditation 

•  Could  use  SysML  to  help  structure  the 
accreditation  artifacts  (and  related 
ecosystem)  and  to  help  automate  checklists, 
document  generation,  etc. 

•  Similar  readiness/approval  tracking  process 
was  developed  for  NASA  Constellation 
program 
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Presentation  Contents 

SERC  RT21  -  GIT  SysML-based  Approach 

•  [Part  1]  Intro  &  context 

•  [Part  2]  SysML  concepts:  essential  prerequisites 

•  [Part  3]  Walk-through  of  concepts  &  examples/demos 

-Includes  SysML-based  V&V  building  blocks 

[Part  4]  Summary  &  Recommendations 


Georgia 

Tech 


SYSTEMS  ENGINE  E  HI 
HU  eIUEI  run  CDrHiil 


Part  41 1691 


Achieved  Project  Objectives 


Representing  System  Models 

With  SysML:  Unified,  Connected,  Consistent,  Explicit 


per  updated  scope  2010-07-20 


Primary  objective 

-  Demonstrate  how  to  address  VV&A  gaps 
by  applying  SysML  and  MBSE  technology 

-  Show  in  particular  how  V&V  can  be 
more  embedded  &  automated  throughout  system  lifecycle 

Supporting  sub-objectives  (via  “quick-look”  approach) 

-  Apply  known  modeling  &  simulation  (M&S)  patterns 
and  develop  new  patterns  where  needed 

-  Demonstrate  approach  by  extending  existing  testbeds  and  examples 
(excavator  testbed,  mobile  robotics,  satellite  systems,  etc.,  ...) 

-  Provide  basis  for  developing  DoD-specific  testbeds 
and  deploying  technology  for  DoD  programs  in  future  phases. 

Terminology 

-  SysML  is  the  Systems  Modeling  Language  (www.omgsysml.org),  which 
has  been  called  “the  new  global  language  of  350K+  systems  engineers” 
(amazon.com) 

-  MBSE  is  model-based  systems  engineering  (vs.  document-centric  approach) 

[Part  41  17C 
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Process  Used 


Enabling  bottom-u p/top-down  hybrid  approach 

-  Iterative  ubiquitous  VV&A;  building  block  VV&A 

-  Software  V&V  techniques  applied  to  systems 
(continuous  integration/builds,  JUnit,  ...) 

Leveraged  existing  examples 


Better  Ingredients. 
Better  Pizza. 


-  Illustrating  technical  approach  in  quick-look  fashion 

-  Adding  VV&A-oriented  extensions  where  needed 

Demonstrated  sample  VV&A  use  cases  along 
multiple  system  dimensions: 

-  system  levels,  tools,  methods,  lifecycle  phases, ... 


Georgia 
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Summary  (per  SERC  impact  questions) 

•  Who  cares? 

-  All  M&S  and  VV&A  stakeholders  (given  benefits  below) 

•  If  you're  successful,  what  difference  will  it  make? 

-  Our  approach  provides  Enabling  Capabilities  (table  rows  below), 

lA/hir'h  rvmrli  ir*AO  D ri rm on/  /#rmor>fp 

V V  !  :lut  1  piuuuooo  1  / Cf  II  1  /jkvaoto 

(table  columns) 

-  Ex.  Related  earlier  studies 
achieved  75%  reduction 
in  M&S  time  and  enabled 

Primary  Impacts 

enterprise  MOEs 
(measures  of  effectiveness) 

methods/tools  MOPs 
(measures  of  performance) 

Enabling  Capabilities 

Reduced 

Time 

Reduced 

Cost 

Reduced 

Risk 

Increased 

Understanding 

Increased 

Corporate  Memory 

Increased  Artifact 
Performance 

increased  analysis  intensity 

Increased  Knowledge 
Capture  &  Completeness 

■ 

■ 

■ 

■ 

-  We  are  endeavoring  to  demo 
basis  for  similar  benefits 
in  this  SERC  effort 
(with  quantification  targeted 
for  future  phases) 

Increased 

Modularity  &  Reusability 

Increased 

Traceabilitv 

■ 

■ 

■ 

Reduced 

Manual  Re-Creation 

■ 

■ 

■ 

Increased 

Automation 

■ 

■ 

■ 

Geygm  11 :  '  . 

Reduced 

Modelinq  Effort 

■ 

■ 

Increased 

Analysis  Intensity 

■ 

■ 
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Deployment  Roadmap  -  Near-Term 

•  SysML  has  a  good,  viable  ecosystem 

-  Training,  tools,  usage  experience,  spec  updates,  etc. 

-  Satisfies  most  criteria  by  K  Morse  et  al.  (NDIA  ref.) 

•  People  can  take  training  and  start  using  (best  way 
to  learn)  at  least  at  the  grassroots  level 

-  See  also  MBSE  deployment  guidelines 
in  our  SysML  102  short  course 


Georgia 
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Deployment  Roadmap  -  M&S  Acquisitions 


•  Suggested  deployment  phases:  DPI  and  DP2 

•  Phase  DPI  -  Apply  to  as-is  M&S  Acquisitions  process 

-  Gain  familiarity  with  key  general  purpose  technology  &  tools 

-  Use  to  help  manage  &  semi-automate  existing  process 

-  Perform  selected  other  improvements  where  expedient 

•  Phase  DP2 

-  Leverage  Phase  DPI  experience 

-  Identify  opportunities  for  major  improvements  beyond  DPI 

-  Develop,  pilot,  and  deploy  related  new  specific  tools  and  processes 
(building  on  general  purpose  tools) 


Georgia 
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Deployment  Roadmap-  Phase  DP1/DP2 


•  Create  &  maintain  SysML-based  VV&A  toolsets: 

-  libraries  (MarginBlocks, ...), 

-  Implement  auto-doc  generation 

•  Use  SysML  throughout  M&S  acq.  lifecycle 

-  Generate  RFP 

-  Manage  requirements  &  objectives 

-  Evaluate  RFP  responses  vs.  R&O 

-  Use  to  aid  in  V&V’ing  deliverables 

•  Implement  risk-based  VV&A  (RBA)  method  using  SysML 

•  Do  DoD  pilot  studies  (w/  other  HLT  VV&A  projects  ...) 

-  Recent  NAVAIR  Pax  River  short  course 

-  Other  DDR&E-relevant  topics  including  underbody  blast 

Georgia 
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Further  Research 


•  DNA  signatures  (model  graphs) 

-  explore  additional  ways  to  expand  and  leverage 

•  Scalability  and  sizing 

-  how  big  (along  various  dimensions)  is  big  enough  today? 

-  where  do  tools  &  technology  stand  today  in  handling  these  needs? 

-  how  are  these  metrics  and  tool  capabilities  likely  to  change  in  the 
future? 

•  Explore  how  SysML/MBSE  approach  helps  with  this 
question  (from  D.  Barnabe  et  al.): 

-  How  do  you  know  when  the  live  system  you  are  modeling  (e.g.,  the 
Internet)  changes  sufficiently  that  your  M&S  needs  to  be  re-V&V’ed 
(and  potentially  updated/replaced)? 

•  Integration  of  multi-language  environments 

-  AADL,  SysML,  UPDM/DoDAF,  ... 

Georgia 
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